Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Categorized responses from the Clojure/ClojureScript survey
Respondent ID Text Category Sub
61448432 Local Adoption. The community is very much concentrated in the US, with the exception of London. In the rest of Europe, not so much. In Belgium we hardly get 6 to 10 people joining a meetup. You see it in conferences too: Clojure presence is much higher at US conferences. adoption
61454845 Needs enterprise uptake and buy-in. adoption
61455773 It's a fairly insular community. adoption
61463826 In Japan... * Very little developer use with clojure. * it is too hard to find clojure developer. * it is too hard to find clojure documents for **non-lisp** programmer (I was non-lisp programmer before use clojure, but I am joyful **lisp style** programming with Clojure). adoption
61506717 Not mature enough language yet to be mainstream in corporate datacenters who think .NET is all you need. adoption
61508083 I think that if it were easier to write Java libraries with Clojure it would become a more compelling option for Java/"enterprise" shops. adoption
61516831 The idiocy of people not understanding it adoption
61629580 Convincing co-workers to adopt (because it's a lisp, non-technical co-workers take a long time to learn, yada-yada) adoption
62117049 Wider adoption adoption
61413662 The lack of a killer app that we enthusiasts can point to and say: "Hey, that super awesome thingy was written in Clojure". The closest thing is Datomic, but it's not open source. We have Pedestal, but that's only awesome if you're already in. Prismatic is cool, but it's not a thing and it's not open source. Loads of cool libraries, but again, only cool if you're already in. adoption success stories
62033834 The use of the EPL, which goes some way to undoing the Java interop benefits. adoption license
61354727 A lack of developers who can inherit codebases. The hiring + legacy maintenance thing. adoption Staffing
61358737 Not really a problem, but because it's still fairly niche there's too much risk in developing in Clojure at my workplace in terms of future hires. adoption Staffing
61369380 This will (hopefully) be solved in time: IMO, Its still a big leap for a long time developer or development shop to jump to Clojure. This is both good and bad. Good: Too mainstream and you get potentially bloated. Bad If you are looking to use it at work you still may have to sell the language. I don't have this problem at my employment, but I know others who do. adoption staffing
61384295 low commercial usage and lack of job positions, start up time adoption staffing
61394145 Still a large lack of developers adoption staffing
61403742 Long term viability and lack of developer resources. A chicken-and-egg problem, but I think it's getting better. Only time will tell. adoption staffing
61824672 Hiring Clojure developers is still difficult. Naturally, it's still a small language and gaining in popularity. Still I worry about it fading into obscurity in favour of say Scala without a more rapid adoption in the wider technological community. adoption staffing
62031990 Mindshare. Hard to convince managers to adopt with limited hiring pool; hard to grow hiring pool with limited adoption, recur. adoption staffing
61420196 Lack of language-level experimentation by non-clojure.core folk. community too small
61384910 I love the language. In my 15 years as a professional developer and general technologist - across security, networking, perl, c, c++, php, ruby, java, linux .... and more communities - I have never encountered a less friendly unwelcoming community. Ruby comes close. But again I do love the language so much that I will continue, for now. community
61391109 Arrogance and smack talk by central clojure figures towards developers who haven't seen the light. community
61397600 Its leadership and the suck up community that wants to worship its own uniqueness and greatness instead of push for faster and more open development. community
61399298 Some people are rather arrogant. Steep learning curve for tools and deployment. Unsure if it will get widespread acceptance or stay in a niche. community
61426782 Dismissive/Combative public attitudes towards differing opinions by prominent members of the community. "Quit sh*tting on our lawn" was a comment indicative of this attitude. Others are not as caustic, but similar in nature. community
61642114 Small community community
61815597 small community community
61444269 Coming from Haxe, the biggest wish I have for Clojure - ignoring cost - is for cross platform development to be embraced as part of the core compiler itself. ClojureScript forked off as something separate to Clojure it seems to me primarily over file size concerns, in order to use the Closure compiler, which rules out arbitrary eval. This makes perfect sense for the trade offs when deploying to the web - nobody wants 1mb js files. But this doesn't scale; if ClojureC were added in order to generate executables, there would be three compilers and at least two languages. Ideally we'd instead have one language and one compiler with a backend API, with macros to do conditional compilation and warnings (eg, you can use eval in js, but the compiler warns you that it can't use the Closure compiler). I realize this is unlikely to happen, as growing up as a Java language Clojure is already firmly anchored in the trade offs of server side development, but it would be incredible to be able to write high performance games and other native apps in Clojure. The biggest reason not to do this is that over the very long term (10+ years), Javascript (with threads) will become more and more acceptable in areas that previously required native code. compiler cross compilation
61458753 Need more cross-host libraries that only provide the abstraction of other libraries, but can switch to different implementations depending on the host/library. compiler cross compilation
61881746 Lack of an easy way to write cross-platform (JVM/CLR/JS) clojure compiler cross compilation
61426179 no self-hosting compiler compiler self-hosting
61444139 Compiler in Java compiler self-hosting
62131101 Not being self hosted (Clojure in Clojure, ClojureScript in ClojureScript) compiler self-hosting
61415606 weakness - production vs development profiles blindsopt - android deployment profiles
61732601 Deployment, particularly of web-apps (and datomic deployment, although that's technically not clojure) deployment
62144283 Limitations in the JVM. It's extremely hard to ship an app that relies on external platform-specific libraries without just as much effort paid to a custom build toolchain for the project. OpenGL would be the best example--ztellman has noted that this is why he abandoned his "penumbra" library. deployment
61362076 I disagree with the creator's stance on distributed programming, and would like to see a semi-official integration of Actor Models like the Erlang systems use. Clojure's concurrency primitives are nice, but unisufficient and often weird to use (like the "agents" that are currently there). Dist sys actors
61372586 Distributed computing is still "roll your own" using mostly interop. Not terrible, but not great. Reducers and core.async have been amazing at tackling scaling up. I'd love to see Clojure leap-frog other JVM languages and be the first to really make use of Graal+Sumantra+HSA [1] [1] dist sys
61378749 Distributed Computing - much of core libs are around performance on a single VM. I would love to see these extended to included distributed node vms. I am aware there are some libraries that do this but I would like to see more focus from the core team. dist sys
61514454 better clojure to clojure runtime communication, for instance erlang like distributed systems. The way to keep growing systems robust and simple is to build them of simple parts. It can be done in Clojure but "we are not there yet" dist sys
61380951 no examples of people using advanced/unique features successfully in real/large projects: refs, agents, datomic. docs advanced
61363632 Documentation. The official page really could use some love. docs
61369244 Official web site design and content. does much better job educating about clojure docs
61382521 To outsiders, the walk-up experience to Clojure is still weird. The various resources (,, cheat sheets, etc.), are not consistently under one umbrella, and often bit-rotted (clojure docs still has v 1.3??). This is in stark contrast to, for example, node.js. Look what's on the front page of 3 prominent buttons. There is a blog button -- leading to a blog that is kept extremely current. There is a core API documentation button -- leading to a part of the _same website_ which is coherent, consistent, and great. There is a downloads button which leads to a clear and communicative table of options -- contrast to what the Clojure download page leads you to: Someone in the Clojure core needs to understand: THIS STUFF IS IMPORTANT. Languages and their communities don't just thrive as a result of technical excellence. For the next 5 million Clojure programmers, who haven't ever heard of Clojure yet, Clojure's web presence __IS__ Clojure. If it's not Rich's core competency or main concern, he needs to empower someone else to take the situation in hand. docs
61383100 The reference documentation is awful. The author really does not want people to understand. It is just one giant puzzle. Case in point - zippers - "See Huet". Or just try figuring out how you are *supposed* to do I/O. Another case - the lovely language page about datatypes, then you look at the API and it is 100% Alpha. Is it real or is it vapor? No way to tell. There are tons of tutorials, I do not want a tutorial, I want a *manual*, a K&R, a Stroustrup. docs
61430635 is uninviting and doesn't help people get started - and the Confluence wiki is a HORRIBLE user experience. docs
61523562 Honestly? Bad publicity. doesn't do it justice. Some more if I'm allowed: * start-up time * unsuitable for mobile * native compilation for small services (where golang excels) * Less important: lack of a "standard" story for distributed jobs (thinking: Pulsar, Storm) docs
61671649 The main website ( is rough. To put it succinctly, it doesn't invite new users (cf. The content is good but incomplete. The presentation is lacking. To verying degress, this problem is pervasive throughout the site. docs
61406186 For me the lack of good public documentation is the single biggest barrier to introducing new people to Clojure. The docstrings attached to functions from the standard library are not sufficient as API docs, and community efforts to beef up the docs have all dies on the vine. This stands somewhat in contrast to Clojure's public projection of itself as a highly idiomatic language with clear opinions. I hope leadership can come from Rich Hickey and other prominent Clojurians that this is an important aspect of the community. docs docstrings
61506037 Documentation assume you know too much about how the language internally works and what the functions goal is, almost across the board. Documentation has too few examples of usage, ESPECIALLY at edge cases. If they do cover a case its the main use case. JVM. dealing with Classpath, different versions, deployment, all of that. I need to know what a WAR file is if I want to deploy this. JVM has a lot of garbage that clojure just doesn't seem to shake. docs examples
61509355 Lack of Documentation and examples. docs examples
61356690 Far too much deprecated information shows up in google results. Docs freshness
61357851 Out-dated documentation. Docs freshness
61372404 Documentation. There is a lot of out-of-date information online, and the documentation quality for the core language and libraries is not nearly as good as, say, Python. Clojure has an amazingly powerful story to tell but it is also a somewhat strange story to many mainstream developers. The documentation could tell that story better, and still be simple. The several excellent books out there go a very long way but they are not enough. I do think the strictness of the CA / ticket execution process does hurt this aspect a bit. Documentation is a way for relative newcomers to contribute, but the process is slow, and not particularly simple or easy IMO. docs freshness
61450927 The biggest problem is the documentation. The core functions need examples and a better discovery mechanism for finding functions for meeting a particular task. Additionally there is no documentation that I can find on the underlying types (PersistentMap etc). This would be ok if you didn't need to know about them but these need to be known when adapting a new protocol to existing types. Since the normal Clojure user needs to know about them a set of public interfaces/classes should be defined a documented. Googling often turns up documentation that is out of date. I'm not sure what Clojure core can do about this but it's a problem that plagues beginners. It's especially unfortunate that ClojureDocs isn't being maintained anymore since the examples were so good. docs freshness
61356567 Newbie friendliness. We need to figure out a way to make people aware that Clojure, actually, is just as easy and fun to learn as Ruby, for example. Also Ruby has killer documentation, not just in the core libraries, but also for third party ecosystems. Rails sucks, but has an incredible wealth of information out there about it. Docs getting started
61357113 Getting started documentation Docs getting started
61357298 Hard to say as I'm deep in it, and take a lot for granted, and work around a lot of issues that come up without thinking. I think this is a good question for folks who have not yet come to the language, and are looking at it from the outside. BUT, if I had to guess, I would say there is some inaccessibility issues for beginners--it strikes me that it is very much an environment/language for folks with a particular experience and mindset: developers who have been around the block, seen the problems with other options, and are both pragmatic but idealistic. This means we are willing to be patient and see "the cup is half full" when a beginner may look at one more stacktrace and say "what the hell?" Maybe; this is supposition though. Another thing I see often--a weakness that I think is also a strength (funny how those go hand-in-hand): the diversity and flexibility that the language allows, combined with the non-prescriptive nature of the community, means that we get a lot of variations on a theme with a lack of strong standardization in general practices. Luckily in web development we have Ring, but otherwise you are on your own--take templating or database wrappers, for example. It's great we have these options, but challenging to figure out good approaches at times, and there is still a good bit of re-inventing the wheel, it seems. But, on the flip side, the language is powerful enough that many solutions to problems are very, very easy to build yourself. And when good, simple,"Clojure-esque" solutions come up (again, see Ring, and Compojure, for examples) the community tends to rally around them. So I think the jury is out on this one. Docs getting started
61358702 The documentation for learners Docs getting started
61376554 I think getting started with Clojure is the biggest problem. First, it's can be difficult to setup your development environment. Second, prefix notation is jarring for most OO and procedural developers. docs getting started
61458923 Too hard to get started. Uninformative error messages. docs getting started
61460466 It's barrier to entry is still to high (mainly due to Maven / JVM ). For example, anyone can download NodeJS and then clone git repos and begin working with the code in minutes. The setup for a Clojure environment takes longer and there is also per project setup which is much harder if all dependencies are not in THE maven repo. More approachable languages (Python, Ruby, Javascript) tend to attract a larger audience. docs getting started
61607064 Getting up and running (especially a simple CLI app.) docs getting started
61814914 It is still very difficult to find a good, simple "Quick-start" guide to point interested parties at. The JVM loading mechanism also means Clojure is subject to dependency hell - which could be solved with a loading system like the one in Node.js docs getting started
61420696 Lack of instructional information about integration with existing systems. docs integration
61503536 a language reference specification is a need. docs language spec
61927350 No standard and only one implementation being (largely) led by one commercial entity. docs language spec
61711115 few examples of clojure scaling to large projects docs large projects
61823990 A broad community understanding of best practice on how to structure state in systems. A typical example is database connections and other 'global' state resources. Stuart Sierra and Prismatic has done some great work in this field, but I feel more examples and discussions are needed in the community to break new ground. docs large projects
61414455 Documentation. Even for core libraries like core.logic, it can be incredibly difficult to get substantial examples of use, pattern/anti-patterns, etc. docs libs
61357711 I think that lack of centralized documentation and listing of mature libraries is the biggest roadblock to adoption. Currently, it can still be difficult for beginners to find what libraries are well maintained and whether they will continue to be maintained. Currently, majority of libraries are maintained by individuals. They can get tired of maintaining the code base, or get it to the point where it solves their particular problem and have no interest of extending the functionality after that point. Another issue is the lack of documentation on how to structure real world applications. Docs Organization
61362001 One coherent place to find acurate info on the language and it direction in the futur. Should be one place with : - reference documentation for every clojure major versions, with examples and remarques - language discovery, first step, download page - commercial support - libraries resources - supported tools Actual web presence of clojure is to scattered around the web. It does not help industrial, commercial acceptance and adoption. Docs organization
61365231 Lack of official high quality up to date documentation and library discoverability docs organization
61378798 The clojure documentation is spread thinly between too many sites. Please consolidate to docs organization
61421137 The official website isn't very good (last I checked it doesn't even mention lein), docs are scattered. I wish there was a more clear path from noob to competent online (I'm always recommending clojure programming). docs organization
61470567 Documentation. Personally, I don't have a problem with it. But the API docs are at once site, extended API docs (with examples) at another ( and out of date, and a third (with tutorials and area guides ( incomplete, and at yet another site. On the other hand, these days,"Just Google It" works pretty well for me. Regardless, it's not access to the information that's so important here, it's the appearance of a clean, unified whole that matters. "These people have this under control," is what you want to be thinking, even if you find a function's doc string is confusing, or an area-guide incomplete. docs organization
61586712 cohesive learning experience. i found 2 books, used, read irc, did blog after blog etc and used clojure docs which is woefully incomplete and not up to date. There should be an obvious official api page like java has, which is always up to date. another great thing would be a setup that shows you the latest info on getting clojure on x (where x is swing/web/android/ios etc). I'm imagining a site kind of how scalatra breaks out different view technologies, but more in depth. make it a hub, the clojure community needs one. docs organization
61363202 There's a lack of good examples about how to structure large clojure projects. Consider Stuart Sierra's "clojure in the large". We've had people hacking at this idea all year long and still nobody has a coherent public example of how to structure a large Clojure app... Docs project structure
61369632 absence of high scale (large codebase) design instructions. Big apps I saw just a mess. docs project structure
61393081 It's hard to settle on an approach to any problem, because development in a dynamic functional style is still so new to most developers. "Just do it" seems to be the only way forward sometimes. Ruby has Rails, which makes so many choices for you that you're almost just left "filling in the blanks", which is quite easy to do compared to striking out to build a new Clojure system. docs project structure
61393284 Lack of good, informative examples of how to structure and manage large Clojure projects. docs project structure
61399032 - no good ide - difficult to refactor - no two pass compilation (helper functions on top, real meat on bottom -- opposite of expectation) - no best practice for code layout - no clear multi-project support docs project structure
61456153 Re-learn how to architecture things coming from years of OOP. Something it's hard to find information on how to structure a big app. docs project structure
61458010 How do you compose a production system out of hundreds of pure functions? docs project structure
61507452 Organizing mid-sized code bases. (>2000 lines) docs project structure
61561288 Developing particularly large applications is difficult in both that there are few established idioms for doing so using names paces and functions. Furthermore lack of a static type system makes large applications difficult. This is why typed Clojure is such an exciting project. Optional typing is exactly what I want. docs project structure
61614852 Lack of support of "programming in the large" docs project structure
61362348 Standardization of code structure / style. Docs style
61376300 The community, though strong, doesn't have the resources to help people write good clojure code. I've written clojure on an off, at work and in my spare time, for quite a while now. I was at the first two conj-es, but haven't been since. Despite all the books and the code, I'm still not sure what good clojure really is. Maybe there isn't one true way, but I often feel as though I'm not using clojure the *right* way. docs style
61563140 Lack of a comprehensive style guide. This is a small point, but let's face it, Clojure is great. docs style
61359180 Tutorials Documentation Guidelines for "idiomaticness" Docs tutorials
61367727 Since it's young, it is very hard to find guides for anything if you're young. For example how to make a game in Clojure (and a full game not just Pong or something). docs tutorials
61371246 Documentation, tutorials, especially for simple things like the REPL. docs tutorials
61415734 Education and lack of educational resources. That said, its improving. docs tutorials
61503167 Need more tutorials like the pedestal client tutorial to support self learning docs tutorials
61524610 Compared to other languages, development and debugging tools are weaker. Tutorials are also weaker in terms of number and how often they are updated (many Clojure tutorials are 1.1, 1.2). docs tutorials
61864029 Would love to have a series of blog articles or something that talks about the best way to do things in Clojure. Since I don't have a Clojure expert to learn from I find myself sometimes unsure of how to proceed with certain task in the language. docs tutorials
61422258 Some blind spots towards web development as compared to infrastructure/big data docs web apps
61505961 Documentation primarily. In the domain I'm most concerned about, web development, more guidance around using ClojureScript idiomatically. docs web apps
61619386 As a web developer myself, I'd expect an important rise in the number of web devs coming from the Rails and NodeJS communities and having a hard time trying to get their heads around web development on Clojure. There are some efforts around a curated selection (a la framework) of libraries such as, but I'm missing others. docs web apps
61903035 Despite the excellent publications on the language itself, getting started with web development is still very difficult. The dissolution of Noir and lack of large, open-source projects to emulate make getting started difficult. docs web apps
61353953 The documentation, for sure. It's _terrible._ Docs
61358108 Lack of good documentation. "Good enough" is not enough. Lack of maturity in most libraries. The main/core/professional libraries are OK, but outside that, there's a wasteland of abandoned libs and poor documentation. Docs
61359525 Documentation Docs
61387029 documentation docs
61403267 Documentation docs
61410639 Clojure is technically excellent. Where it suffers is in documentation, as well as in the stability of some fundamental libraries. It's a bit off-putting to see something as fundamental as the JDBC library in an alpha state, with recent breaking API changes. The libraries may be excellent, but it makes the stack a difficult sell to my more conservatively minded colleagues. docs
61425372 Docs docs
61432003 Inconsistent documentation, it's frustrating to troubleshoot for hours just to realize the documentation is incorrect. docs
61444251 - Bad Documentation Style , If There's Any! - Bad Performance - Time to find proper Command/Library - Weak/Complex web tools docs
61447962 Documentation, while good, is not as good as JDK Javadoc, for example. docs
61453412 Again, that protocols aren't built into the language at the bottom. Also pattern-matching style function dispatch a la Haskell would be super sweet. Also the official documentation sucks hardcore, and the unofficial documentation sources (clojuredocs et al) also kinda suck. I think Cognitect or whoever should put together something like clojuredocs which stays up-to-date, but with better function discovery features. also why no dissoc-in? docs
61457725 Approachable, pragmatic documentation. docs
61457842 Dearth of resources (tutorials, documentation) for learning libraries. Generally core stuff is well documented, but newer things and many libs, even commonly used ones, are poorly documented. docs
61475468 Clojure seems effective for the very smart but I find a lack of documentation and recommended practices from Cognitect frustrating. E.g. is still a go-to site for me even though it only targets Clojure 1.3.0. Why doesn't Cognitect provide something like this? The hangup of not accepting any documentation or tutorials that don't have the protective halo of the Contributor Agreement is frustrating. There should be an active effort to identify the best docs, tutorials and practices out there (i.e. "useful shit") and collect them under one roof. Source: I can currently only program in Clojure very part-time. docs
61538621 More promotion. Better documentation and tutorials. Clojure presenters a and advocates can have more real-life exples docs
61557043 Lack of high-quality documentation, as well as unsuitability for scripting tasks (Which is a shame, given Leiningen is awesome). docs
61663059 Official documentation. Un-official documentation is fantastic. docs
61695087 A lack of continuity in the development story and established best practices. Though RoR is overbearing at least the whole of the community can rally behind it. docs
61895028 There should be a better online (with robust offline "mode") documentation-system maintained by the core Clojure team. Something like, with the ability to point at external docs of the user's choosing, e.g. docs available at some github http endpoint (with prefs stored in localstorage): Such a project, very close to the core "Clojure effort" would help to bolster the community and define a standard for documenting Clojure projects. docs
62037074 Documentation for more obscure methods and macros is nearly impossible to find or too terse to understand. If a library is not well documented with plenty of simple examples it might as well not exist. docs
62043453 Documentation, without a doubt. docs
62067601 Poor documentation. It seems that while this is often pointed out by the community, efforts stall (we're forever waiting for someone to finish porting clojuredocs.orc, etc) and the language stewards don't care about it. docs
62134361 "Where are the docs?" "Read the (tests|docstrings)." "Did you just tell me to go fuck myself?" "I believe I did, Bob." docs
61359557 Error messages: common mistakes often lead to very strange compiler exceptions. The community stance of 'unspecified input has undefined behavior and should not be tested' should not apply in this case. We need to define those cases and stop showing developers stack traces from inside the compiler. Errors messages
61361914 good debugger, funky error messages, slow startup Errors messages
61364869 unhelpful errors or stacktraces depending of the environment (nRepl with Emacs or not etc.), dynamic typing for big projects, records and maps are similar but not identical (can lead to surprising problems) errors messages
61365302 errors are often only found at runtime; error messages are sometimes hard to interprete (anonymous functions, etc.) errors messages
61368478 Esoteric error messages and inline core function documentation. errors messages
61375964 Error messages that are difficult to understand errors messages
61377415 arcane error messages errors messages
61429358 I think the bar has been set by Ruby and Python. Clojure needs to give error messages as least as good as they do and also needs to do better at loading files and projects that may have an error in a file -- the file should still partially load while simultaneously alerting the user to the issue. errors messages
61355663 Obviously, cleary, evidently, manifestly, patently, without a shadow of doubt the unhelpful and maddening stack traces CANNOT PROCESS RULE __q_40123 Errors Stacktraces
61356354 stacktrace is not so good Errors Stacktraces
61357156 unreadable stack traces Errors stacktraces
61357779 Debugging: in JVM version, stacktraces. Poor EMACS and NREPL integration, and some bad choices made in it. Debugging REPL entered code (no line numbers, so it's lost). Etc. I've been a Lisper since 1978 (sic); I pity those new to it trying to use Clojure on the JVM. Errors stacktraces
61360227 stacktraces are horrendous Errors stacktraces
61363051 Exceptions are leaking Java (something like slingshot should be the default). Errors stacktraces
61368731 Stack traces errors stacktraces
61369322 Stacktraces are still hard to read errors Stacktraces
61375494 Stack traces are hard to read, mixed in with Java-isms as they are. And I'd like a proper debugger. I've never been a huge user of debuggers in other languages, but when you need it, you need it. Something like Emacs' edebug would rock my world. errors stacktraces
61376813 The stack traces, on nested anonymous functions can get pretty hairy. Most of the time I can figure out what the problem is, and then the information in the stack trace is very clear, could we have better behavior there? errors Stacktraces
61385195 Debugging Clojure can be a pain in the ass. With its dynamic typing (which can be great) it's sometimes hard to catch subtle errors that the compiler could have avoided otherwise - at compile time. Also, the stacktraces are ugly at best. For beginners not really helpful and sometime even misleading! errors stacktraces
61386076 Stack traces/debugging/profiling are still a pain. Error messages in general Null pointer exceptions errors stacktraces
61395568 Error messages - the stack-traces are hard to read and require understanding of the implementation. errors stacktraces
61405381 If I had to pick something, and this isn't something that really seems to hamper my work or hobby use of Clojure very much, it would be the desire for better ways to make sense of stack traces when something goes wrong (possibly something in a JVM library, for example). Really, I'm still pretty spectacularly happy with where Clojure is right now, and I recognize that my lack of a good answer here probably just indicates that I'm not successfully trying to do "enough" with Clojure to find warts and problems yet. errors stacktraces
61414090 Vague stacktraces errors stacktraces
61418011 stacktraces errors stacktraces
61419796 It's a pain to deal with JVM tracebacks for things like syntax errors. I'd really rather Clojure have its own traceback formatter with knowledge of sub-expressions and so forth. errors stacktraces
61429681 Error messages (stack traces) errors stacktraces
61436873 Stack traces are often needlessly long. Also, debugging is really difficult. errors stacktraces
61447153 Slightly cryptic stack traces (the destructuring ones are particularly egregious). errors stacktraces
61457256 I can't think of any serious issues in Clojure. But reading Clojure stack traces is painful. errors stacktraces
61507258 Stack traces and interactive debugging (in emacs at least). errors stacktraces
61538638 Incomprehensible stack traces on JVM. errors stacktraces
61557192 Modeling enterprise data: I had a hard time finding comprehensive documentation on this fundamental topic. Reading and understanding stacktraces in the REPL is difficult. They are noisy and identifying the source code that fails isn't easy. Why isn't the failing source code directly displayed, with its line numbers and source file name? Profiling memory usage is difficult (with Java profiling tools like JVisualVM). errors stacktraces
61584767 reporting errors, stack traces errors stacktraces
61595908 I've probably got used to it by now, but the cryptic stack-traces are baffling when trying to teach newcomers. Usually the conversation goes: 'ah, a WTFException', 'that means that <X>', 'how on earth did you know that?!', 'I've seen it before...' errors stacktraces
61862305 stack traces errors stacktraces
61885408 Atrocious stack traces Java culture leaking in errors stacktraces
62096390 The JVM error message errors stacktraces
62107896 It's really hard to think of any! If pressed, I'd say the weakest points are: the default error reporting/stack traces can be hard to handle. And the ns macro syntax can sometimes be a bit confusing. Although I feel that less now that I've stopped using 'use'. errors stacktraces
61366238 Debugging errors via stacktraces can be difficult. errors
61391697 I believe that feedback to the user/developer needs to become a first-class priority within the Clojure runtime and compiler. This means a much greater focus on identifying errors, including user errors, and providing real feedback about the cause of the problem and guiding users towards a solution. It means that a compiler error should be reported in an organized and readable fashion ... not as 100 lines of nested stack trace. It means that the compiler should trace its behavior in such a way that the true location of errors can be reported (contact me offline for a more complete discussion of this - Clojure is, for me, very pleasant to work in ... right up until I have a problem, such as an invalid namespace definition, or passing improper parameters into a function. At that point, it can be hair-pulling exercise to extract out the details of what went wrong so that I can identify where to fix the problem. I think many would see the current status quo as a barrier to entry: "I guess I'm not smart enough to use Clojure". No such barrier should exist, as in nearly every real way, Clojure is the simplest and easiest language I know ... but the current indifference to the needs of the user creates an artificial message that Clojure is only for the Rich Hickeys and Stu Halloways and Cognitects of the world. errors
61395916 bad errors :) errors
61404780 Error messages errors
61406536 I'd like to see some functions become less "forgiving". For instance, `(:foo 1)` and `(get 1 :foo)` both return `nil`, but it seems to me it would be more helpful for them to throw an exception. Calling these functions on a number (or other incompatible objects) is, in my experience, always a programmer error and throwing early would make those errors easier to find. errors
61407648 Being "reader based" is both a benefit and a curse, having code "run" when "compiling" ( i.e. lein compile, mvn compile ) can lead to some interesting, and confusing bug hunting. errors
61408607 Error messages / debugging! This is sure to remain a favourite. errors
61418242 Stack traces, debugging, error messages, documentation. errors
61435766 it's not friendly to new users given the poor error messages at language level, a strategy copied by pretty much all clojure libraries. errors
61438309 those runtime errors that do not point to a specific place in the code. errors
61473886 hard to interpret error messages errors
61526708 Some of the compilation errors are just weird. errors
61662936 The poor error messages maybe. errors
61763243 Clojure's weak spot is the information given at compile time, mainly for stack traces, but also type information. (I'm aware of core.typed, but there is zero documentation or 'community use' at present). errors
61843098 Error messages could be improved. errors
62040537 Error messages, etc. Lack of transparency in core dev. Lack of transparency in official contribs dev. errors
61511825 it's main goal, targeting the jvm could be it's weakest point. the jvm is a great platform, but is not going to be as dominant in the future as it has been this years. All its libraries are wrappers of some java lib/fw and they are not easily portable to other platforms. I am more interested on BEAM than JVM, for now. host BEAM
61403745 I don't know that it's a glaring weakness, but I think some more focus on ClojureCLR would help to grow the community. I can't conveniently use Clojure on the back end for the Web because I'm constrained to IIS on the server side. If I could easily use ClojureCLR in a ASP.Net application, that would be fantastic. host CLR
61953299 Clojure clr is interesting but very poorly documented host CLR
61369790 Lack of native compilation. (Targeting iOS for example) host ios
61416457 Target JVM and enterprise space - excellent Target browser/JavaScript - excellent Target iOS - pleeeeze host ios
61489627 Lack of support for Objective-C runtime as a deployment platform (for iOS development) host ios
61498080 Its primary tethering to the JVM has given it powerful host interop, but the unavailability of a robust C/C++/Objective-C runtime prevents its use in my primary area of development, iOS. host ios
61545857 It does not run on iPhone/iPad host ios
61357943 The JVM Host JVM
61358983 It's biggest strength is also its biggest weakness. It'd be nice to be able to ditch the JVM if desired. Host JVM
61359924 You have to learn Java alongside Clojure through the stacktraces. Host JVM
61360439 It “feels” heavy because of the JVM. Host JVM
61364472 Java ecosystem. host JVM
61377935 The JVM as the central component of Clojure is both it's biggest advantage and it's biggest downside. While the Java ecosystem is very large and fairly comprehensive, the culture of Java is to pretend that it lives own it's own. Integrating more closely with the core OS is time consuming and often fraught with difficulties. Just as one small example, it is extremely difficult to unpack a zip file in java and still retain original ownership/permissions. host JVM
61382469 Dependence on the JVM is a two edged sword; there are a ton of benefits but ultimately it is controlled by Oracle. Oracle tends to consume and destroy successful things. Clojure also needs a non-JVM host that can be used for writing scripts. Finally, Clojure Docs needs to be updated :D it's an awesome site, just... out of date. host JVM
61389350 The Clojure's most glaring weakness comes from the JVM. While the JVM brings a lot to the table, there is an impedance mismatch it an UNIX-based systems. It would be great if our tooling ecosystem could help overcome this. host JVM
61399801 That the default version depends on (the huge) Oracle Java JDK, rather than being a simple C-based portable native compiler. host JVM
61411492 The armies of mediocre java developers, and their mutable java code creeping into the library eco-system. host JVM
61419625 Too tied to the JVM. Should have it's own VM. host JVM
61420458 Being wedded to the JVM for its primary implementation is still Clojure's biggest weakness. It brings a lot of benefits in terms of adoption and library re-use, but puts hard limits on Clojure's runtime performance and prevents it from being useful as a scripting language. host JVM
61438146 The JVM and its ecosystem. It's too slow for numerics, too bloated to deploy for client-side apps on the desktop or on iOS, too enterprisey to be as productive as ruby/python for web development. The world is web dev and mobile and enterprise. Clojure's sort of plausible for enterprise because of java, but that's it. Concurrency is usually irrelevant. host JVM
61439922 Too tied to the JVM... I want to run a solid implementation on ARM! host JVM
61470790 Java host jvm
61543134 The over-dependence on the Java stack. Somewhat ironically this is also one of Clojure's greatest strengths. host JVM
61724038 Oracle host JVM
62061467 If you don't use java much, I don't think it as easy to get going as one might think; There are many things that do not work as advertised out of the box (mostly on osx, but even on linux); host JVM
62062231 too tied to the jvm ecosystem host JVM
61359800 Lack of native compiler/Clojure in Clojure Host native
61413153 No good native implementation (clojure-metal/clojure-c). host native
61547439 The alternative implementations should gain more attention and support from the community. I personally don't like the JVM because memory usage is often more important for me than CPU usage. I was thinking about using ClojureScript with node.js, or even ClojureC, but it would be so much more painful: tools like Leiningen and most libraries focus on JVM, and _some_ have some support for ClojureScript. But experimenting with ClojureC or clojure-py would take a lot of effort. host native
62017172 Performance and C library interop. These sort of go hand in hand, but are also the main reasons I would love to see a version of clojure on the llvm. Python, though slow, does well in the scientific computing space due to relatively easy interop with fast C libraries. host native
62027179 I don't know much in general not just clojure to judge awesome clojure but I think a distinct extension for pure clojure would be nice. clj for jvm cljs for js c or cl for pure clojure (that hopefully runs regardless of target host) host native
61378427 Right now, I just wish I could run it on a Ruby VM :) host Ruby
61362081 From the technical point of view, maybe the lack of tail-call-optimization on the host platform (JVM), so you must remember to user recur in your clojure code, and the lack of pattern matching by default for function arguments. But those are really minor points. Host TCO
61402303 JVM is great, but no longer a goto choice for portability (think mobile). Clojurescript may be a passable alternative, but language differences are a concern. host
61383562 it would be nice to have better Android app development support host Android
61411963 Missing documentation on how to create in a straightforward manner JARs which look and feel exactly as if they had been written with Java; esp. regarding the "translation" between Java packages and Clojure namespaces. I.e.: to enable Java programmers to "import com.example.coolclojurestuff" interop Java usage
61360510 Lack of easy integration with host OS functions and hardware. Interop OS
61367994 Clojure is incompatible with several Java libraries because when importing a class it runs its static initializers. interop run static initializers in compile
61368648 Interop with existing libraries on the host platform is great, but lots of libraries don't share Clojure's philosophical ideals, and create a paradigm mismatch. On the whole it's obviously useful to interop, but sometimes it's Simpler to rewrite things in Clojure. lein is fine as a build tool, but not for deployment tool. interop
61387688 Async. While core.async is coming along nicely, I still don't see why some of the core functions can't support some async capabilities. lang async
61368835 Except for the slow pace of change in contrib libraries (I understand why core changes as slowly as it does), most of my frustrations with Clojure are things that couldn't be changed without the language ceasing to be Clojure (and becoming Haskell, or whatever). The frequently surprising behavior of runtime initialization and AOT compilation has bitten us several times though, and I could wish non-AOT and AOT code were just more _like_ each other. lang AOT
61371499 AOT is a second class citizen, slow to build, quirky on deploy lang AOT
61422026 AOT is a second-class citizen - excruciatingly slow builds and corner-case differences between AOT'd apps and compiled-at-runtime apps. lang AOT
61506977 Edge-case discrepancies between AOT and compiled-at-runtime Clojure. Gotchas and excruciatingly slow build times. lang AOT
61685092 Number of class files when AOT lang AOT
61356482 The atom of agents - i keep constantly running in to situations, where I need to maintain handles on generated agents, channels, or other atoms. All books and documentation say "don't put mutable objects in atoms". Lang Atoms
62028399 It's really hard to use unboxed values. It requires advanced tactics to stop the compiler from doing intermediate boxing. And it's even harder to pass around unboxed values from function to function. lang boxing
61376955 The monolithic Java-based compiler. lang compiler
61705760 Compressing function names and meaningless function names - aget, aset, conj, assoc, conde - turn code that could be highly expressive into meaningless soup that repels developers with any aesthetic sensibilities. lang fn names
61422397 Needing gen-class to extend with custom init lang genclass
61361849 I miss some things from Haskell-language family, like automatic partial application (need to use partial), (.) operator for function composition (need to write comp), missing pattern matching (core.match is not sufficient), missing ordered maps (need to use flatland's ordered map). Lang Haskell
61525659 - Most of the time I do not use sequences in a lazy way and it often bites me - Dynamic typing (Stu said static typing only prevents easy mistakes. I agree, but I still make these mistakes and would like a tool that helps me with that) lang laziness
62047422 The mix of lazy-seq and non-lazy functions. I have rarely had a use case for lazyness, so it has only caused problems when results mysteriously aren't realized and minor performance penalties. It is one of the harder things for a beginning clj dev to wrap their head around. lang laziness
61906379 Proliferation of bizarre macros that complect things (I said it) you have to be "in the know" to figure out what they do -> | I'm a newbie so these things stick out for me now. lang macros
61354371 After all these years I still find explaining problems with namespaces problematic. Lang namespaces
61357777 File hierarchy and namespaces. I don't see why they have to be bound so tightly. Lang Namespaces
61371984 I always have a hard time figuring out how to use/require/import stuff in my namespace (be it in a file or at the REPL) I think a clear single entry point for documentation would help best. vs vs ( vs !!!) lang Namespaces
61378384 A weakness about what? About adoption? => A reasonable debugger About mobile? => Fingerprint, memory consumption (unless you think clojurescript) About general use? => Startup time (JVM related) About the language? => Lousy namespaces and many cryptic compiler error messages. Regarding adoption I'm not sure a huge community is desirable though. lang namespaces
61400706 clojures namespace handling. Clojure defaults to immutability almost anywhere but forms like def modify the current namespace. This leads to incidental complexity and annoying problems with code reloading at the repl for example. lang namespaces
61424530 Not sure how to articulate this, but namespaces seem to be implemented in a strangely non-Clojure way currently. Surely they should be more like maps, with the environment being a versionable immutable value, instead of the rather scarey mutable vars system. I have servers which cannot be stopped, and I always get a bit worried when I :reload namespaces, even though I've tried to make them all stateless and manage their lifecycle well. On another note, I feel Clojure could learn a lot from Smalltalk. I despise the culture of emacs and the text-based world. What Smalltalk showed us, back in the 70s!, was that programming can be a well-rounded, extensible, fun, comprehensive, self-explaining, approachable, multi-sensory experience. There is great potential for there to be a Clojure programming environment, with an image backed by Datomic, which replicates and builds on the Smalltalk environment. lang namespaces
61585256 Namespace syntax is confounding to the beginner. Do I quote it? Stuff in a vector (and quote too)?? Up to date examples in the doc would be really helpful. For a lot of libraries some basic information is assumed and for the beginner this could be a hurdle not worth jumping over. lang namespaces
61717623 Namespaces are a horrible, broken mess. They are a wildly complected nightmare. lang namespaces
61889778 Namespaces are a poor alternative to modules. We sometimes see ourselves in a situation where we must opt between code duplication (quasi-verbatim ns in several projects), littering fns with extra parameters, or using mutability. See Newspeak or even Scala for better alternatives. lang namespaces
61376694 I wish the core abstractions used protocols! lang protocol internals
61489070 managing native resources lang resources
61369620 The sequence/collection API is very patchwork and inconsistent. In partcular: Next vs. rest (+ nil-punning), the confusion between lists and seqs in the API (e.g. list*). lang seqs / collections
61381362 For my personal use, mostly things like good support for static methods (other than backed by Vars as with gen-class), nested loops (see Q. 10) etc. Nothing deal-breaking, to be sure. lang static methods
61355750 Implementation details leakage (stacktraces, into written with reduce -> can be used with reducers, recent hash code of sets discussion, ...) Lang
61435062 Java and its GUI are in with one install, you have layers. I tried to implement simple logical expressions and your functions can't do true and false properly -- there should only be ONE possible way to represent FALSE or TRUE and (not TRUE) is FALSE. Even the comments within the compiler (great idea) need to be proofed by at least one other person... lang
61397764 reader macros lang reader macros
61451799 Functional programming is still a foreign concept for mainstream developers. learning FP
61577391 Not about clojure in particular but coming from java it's much harder to find solutions for problems that are functional because most languages are object oriented. It makes the learning process much more difficult. Clojure itself, the language, is very easy to learn. It's the functional aspect that makes it hard, at least for me and other people I know. The advantage is that the community seems to exist of people who are REALLY interested and are doing some amazing things. learning FP
62091157 Not enough people exposed to functional programming. learning FP
61398267 Coming from an OO, it was hard to develop a sense of design aesthetics; how to decompose functions into namespaces, what sorts of coupling are problematic, etc. Also, tooling: how to use the repl and automated tests effectively, how to decipher (and avoid) exceptions. learning OO to FP
62098469 Lack of standards the beginners could cling to. learning style
61376166 Still learning all the great existing features. The only part I struggle with is the functional aspect and I consider that more my problem in learning idiomatic way to do things than blaming the language. learning
61404384 Approachability to outsiders – a lot of the conventional wisdom assumes the kool-aid has been drank. learning
61408706 learning curve learning
61408847 It seems hard to read/understend/enter for programmers who are not used to it. Therefore a lot of convincing work is needed to make a team give it a chance. learning
61415145 Difficulties in bringing new people to the language. Acceptability. learning
61431440 Clojure's greatest problem, is perhaps, it's greatest strength: it's heavily Lisp influenced. Many programmers I know are still... "indoctrinated" to a Java OOP world view and would need intensive "un-learning" to appreciate the world view offered by Clojure's Lisp heritage. learning
61445363 The learning curve for non-Java programmers is high and steep, especially as regards deployment. Java interop is surprisingly easy in spite of sparse previous Java experience. learning
61470607 Still weird for new users. People are a lot more receptive than they used to be, but we need to invest in making it super easy to get people hooked. learning
61478906 Also it's best asset, is the paradigm shift in thinking required to express the simple ideas. Takes longer to learn what to do than to actually do it, for many many months, even as a seasoned developer. learning
61503225 Clojure is initially unapproachable due to the setup and stacktraces (java). Since development is Repl driven, the developers I have been working with don't know how to do that kind of development and resort back to python/ruby ways of scripting. A good working setup through Lein is nice, but the real a-ha moment is running an interactive repl that is tied to the text editor where code loading is a keystroke away. learning
61507631 Onramp for newcomers is still too difficult. learning
61543218 Making the beginner path more bearable learning
61550787 Steep learning curve learning
61575086 Noobfriendlynessless learning
61360761 Learning curve is steep, though satisfying. learning
61507414 coherent method of finding and grabbing libraries - clojars + sometimes getting a github URI isn't good at knowing libraries. libs dep mgmt
61362436 Difficulty in finding the correct libraries. Interop is cool, but when you want to do things in clojure style... Libs discovery
61371621 Lack of cohesion. This includes the "standard library" of core.*, tools.*, etc. libraries as well as the fragmentation of development environments. I feel the Clojure *ecosystem* would be more discoverable and would project more reliability if Clojure's web presence were more clearly laid out. At this point, Github acts as the table of contents for Clojure's standard library, and folks have to depend on various other websites either for lists of libraries for particular domains, or more narrative/practical documentation that could be made available within the official Clojure web presence. While things are moving fast, as with ClojureScript, I can understand not taking the time to consolidate information about various efforts, libraries, and experiments in one place. However, it seems that JVM Clojure has reached a level of maturity both in the language implementation and ecosystem that the lack of a cohesive body of knowledge does not do justice to the language and community. libs discovery
61436627 As a very experienced Rails developer who completely gets + like the Clojure "way", finding libraries + documentation + community remain the biggest challenge, and a major step down from that world. libs discovery
61525553 Fear of batteries included, opinionated, comprehensive frameworks for web specifically. Killing adoption. libs frameworks
61382140 Incanter is a great library but needs much more attention and development to be on par in terms of performance with other data analytic libraries found in other languages. Ideally, Incanter would be much more performant (comparable with C) and offer a clojurescript version that offers D3-esque visualization capabilities. libs Incanter
61379578 native data analysis/linear algebra libraries libs linear algebra
61361235 Lisp Curse: every domain has a dozen libraries, each of which implements 30-60% of what is needed to deploy a non-trivial app, and none of which integrate well together. This is exacerbated by the community's hostility to (and ignorance of) frameworks. Beautiful algorithms are easy. Integration is the hardest and most time consuming part of any software effort, because that is where all the edge cases are. clojure has no solutions for this. Libs Lisp curse
61367025 Too many choices for libraries doing the same thing. The incredible amount of options when it comes to things like logging, database/ORM, etc mean that choosing the one that will be available long term is difficult as the whole community isn't behind a single solution. Seems counter-intuitive, but for example on server side, you have to choose from ring, noir, aleph, pedestal, http-kit, immutant, vertx, etc. For a "newer" community, it would be helpful if the options for web server had a single or even two options as then both would likely be supported and exist long term. As it stands right now, no one option is the norm other than ring somewhat and so any choice can easily be deprecated within 6 months to a year which is not good for production usage. libs Lisp curse
61420973 Better statistical and scientific computing libraries libs math
61422904 Not really a weakness of the language but for the kind of work I do, scientific programming, it does not have the same level of library maturity and community as Python with Numpy, Scipy, Pandas, etc. I am not sure it will ever have enough to convince people to make the jump. libs math
61437918 From scientific perspective, lack of good numeric libraries for matricies and ND arrays (compare to say SciPy/NumPy or Matlab) Hard to interact with linux/BSD OS, i.e I still tend to write many bash scripts / C tools libs math
62084116 There are not high-quality Clojure libraries that work with scientific computing libraries, like those that NumPy/SciPy make accessible to Python users. libs math
61360440 Many libraries still "too young" Libs maturity
61365059 Libraries/frameworks not as developed due to age libs maturity
61419318 I fear the community is too small to sustain a good set of libraries. Instead it seems to become the same clusterfuck of half abandoned / derelict libraries as in Python / Ruby where it's often necessary to read to code line-by-line to trust it doesn't completely fuck your application over. This as apposed to Java / C where there are good trusted and established libraries where the risk of using them is more limited. libs maturity
61420724 The fact that the ecosystem is still under development and thus many libraries don't exist or are not battle tested. libs maturity
61430812 lack of libraries libs maturity
61437337 Lot of libraries having overlapping functionalities with less documentation. Less of batteries included frameworks for webdev, example Luminous Web which was addressing webapp development doesn't have a good authentication mechanism supporting various openid providers etc which are taken for granted in other languages. Friend's looks promising but documentation is not comprehensive etc. libs maturity
61444892 Libraries are still immature. libs maturity
61457002 The open-source Clojure library / tooling ecosystem is focused too much on developer convenience and not enough on quality, stability, and innovation. libs maturity
61526369 A lot of the libraries, while of high quality, have not yet reached a stable 1.0 release. The language itself: not exactly a problem with Clojure per se, but a lot of people are turned off by Lispy parentheses.. their loss.. but.. :-( libs maturity
61567109 ClojureWerkz. I find their pretentious declaration of 'this is the right way', especially when it comes to their documentation, to be damaging to the Clojure community. I find their docs to be completely unreadable and their projects never pass a sniff check of 'go read the code'. Obviously the answer is for me not to use these libraries, but I am concerned that their hold over the community may make new libraries have a similar convention. libs maturity
61616064 Sometimes the ecosystem (third party libraries) are either hard to find, or have a very short life-time (dropped after several month of development). that makes it pretty difficult to find what you need. it's not really a weakness of clojure: but I find it still hard to structure code (especially in bigger projects -> month of development). libs maturity
61677990 Immature and poorly documented libraries (RTFS required often). libs maturity
61778242 The libraries are often immature and sometimes not very well designed. libs maturity
62027855 The one that I've had several times is that the "core" JDBC library is far from ready for heavy use. It only exposes a small fraction of JDBC functionality. It obscures things that could readily be made available. That is just one I have personally stumbled on repeatedly. The maturity of the libraries, especially those with the core name, is the most glaring weakness I see. libs maturity
61545043 Lack of a good data visualisation library (I come from R) libs visualization
61383636 Still much, much too hard for people interested in joining the community to get started building and deploying web apps. I believe this stems from the community emphasis on individual libraries and open disdain for frameworks, as well as the dependence on emacs as the main editor. I fully agree with the community that libraries are preferable in fostering a healthy ecosystem evolution over the longer term, but there's something to be said for a set of well tested libraries that just work well together for common tasks beginners want to accomplish. It's my hope that LightTable can become that approachable editor. libs web apps
61614957 In the web domain, Clojure can't beat Ruby in terms of frameworks for productivity such as Rails. This is a needed killer app if Clojure is to make a huge impact in full-stack web development. libs web apps
61355767 I think there needs to be a broader core.* toolset to match python's "batteries included" approach. There could be a* approach for not 100% vetted libs. Small enhancements like useful & friend are hard to evaluate on a day to day basis, and newcomers have to rely on arbitrary metrics at first (is the author a known contributor, who else is using this lib ?). Libs
61422764 (relative) lack of idiomatic libs libs
61478482 Reliance on existing java libraries and frameworks. libs
61516579 I think the standard library should be more comprehensive (like include a socket programming api). libs
61431675 Immature native libraries. libs maturity
61371645 Adoption by big companies marketing adoption
61372704 Adoption is the aspect I worry about most. I love using Clojure and want very much for it to be a viable option at any company. How do we get developers to know about Clojure and to use it - especially over JVM languages that appear to be easier to get started with. marketing adoption
61378384 A weakness about what? About adoption? => A reasonable debugger About mobile? => Fingerprint, memory consumption (unless you think clojurescript) About general use? => Startup time (JVM related) About the language? => Lousy namespaces and many cryptic compiler error messages. Regarding adoption I'm not sure a huge community is desirable though. marketing adoption
61362264 The relatively common belief that dynamically typed languages lead to hard-to-maintain systems. Perhaps Typed Clojure might be enough to help convince people who hold this belief that Clojure has their concerns covered? Marketing Dynamic langs
61589629 Hard to sell to enterprise people marketing enterprise
61360991 The world needs to be better-educated about Clojure's strengths. Marketing
61363697 Nothing really, we just need to keep growing the community. marketing
61494566 Some docstrings of core functionality are outdated. The focus in Clojure marketing should not be targeting developers from foreign languages anymore, but widely (in schools, education etc.) presenting Clojure as the king of abstraction in Computer languages that everyone can learn without many knowledge about other programming languages or IT-specific problem domains. Clojure makes it finally possible to learn a craft from the top of its evolution. marketing
61501343 It's difficult sell still. marketing
61529694 The "different-ness" from almost every mainstream language, and working to convince people from those environments that it is a positive. marketing
61885850 It's a "hard sell." marketing
61885973 Marketing! It seems to me that Clojure community doesn't stress enough on marketing themselves , as Scala people do. Even though Clojure may be better than Scala, but the lay men do not have awareness. marketing
61910727 Poor marketing (terrible website). Many abandoned libraries. marketing
61434918 There is no all-in-one bundle or simultaneous release of Clojure/editor/related libraries as there is within the Eclipse ecosystem. In my company every library, no matter how small, requires separate approval, so I want a single umbrella release in a single download for the purposes of satisfying management and compliance. An all-in-one bundle of high-quality Clojure+libraries with a predictable release schedule would greatly help marketing batteries included
61364754 AD hoc implementation of fundamental abstractions misc
61369405 A rush to "decomplect" without a solid understanding of the implications on the composability requirements of such an approach. (not= :decomplect :composable) misc
61393073 Accessibility to new users. misc
61423679 Sometimes the community (there's exceptions) can be blind to places where other languages are better. I think this is because many people stop 'looking' once they've found Clojure, and assume if it was necessary, Clojure would have it. misc
61438153 clojurescript cross-browser development ! misc
61507500 The flexibility & power of clojure is both a blessing and curse. It gives the programmer the chance to build great software systems quickly and easily, but can also make it very difficult for new comers. It gives you plenty of ways to write something in a more complex or unmaintainable way, and you generally have to work through those implementations before you find a better way of doing the same thing. Fortunately, refactoring is also quick & easy. misc
61668365 Community inertia. Clojure is doing absolutely the right thing by not compromising on immutability; however this makes it harder to sell to the ruby/python types in my office. Golang has been an easier sell because it still feels imperative enough. misc
62112382 Most people rarely create macros, so they don't need homoiconic syntax. They'd prefer Clojure to have a more Pythonic syntax. misc
61366833 Nothing in particular, mostly minor stuff. I might be mistaken about this, it might be possible, but it would be cool to be able to extend data types to implement the interfaces Clojure defines. I remember trying to extend patterns to implement IFn, but that wasn't possible (unlike ClojureScript, I think?) misc
61381351 that is really hard to say. I think it would be nice to have some more polish, there are lots of little corners marked experimental or alpha, or not documented, etc misc
61417058 I haven't identified Clojure's most glaring weakness yet. misc
61355531 it's a Lisp perception parens
61358938 People fear it. Perception fear
61361958 Fear of lisp. Perception fear
61365765 Still difficult to get people to take the plunge on it (i.e., when coming from more imperative backgrounds) perception fear
61370572 I guess the hardest part is getting new developers to clojure over that initial mind hurdle. Once they have recovered from the mind twist, then they are converted for life :). perception fear
61372144 I think parentheses scare people. Also not everyone loves the JVM (but my day job is Java, so I like having access to all that Java stuff). perception fear
61383954 How different it is from other mainstream languages. perception fear
61384877 In our shop, it's mostly the perception of being an arcane Lisp dialect that keeps many from wanting to try it perception fear
61438218 It is so different that it is difficult to get everybody on board. perception fear
61616546 Clojure is a dramatic change from "mainstream" languages. I suspect many developers, and companies are - and will be - reluctant to use it. Does this mean developers should continue investing time in it? Or would they see a greater ROI by applying the functional lessons learned from Clojure to projects implemented in more "mainstream" languages? perception fear
61627599 People are nor willing to learn it. perception fear
61445206 1. Functional programming is not all that popular yet as it is supposed to be. 2. Building case to convince people to adapt Clojure. perception FP
61357583 It is, or looks like it is harder/weirder than other languages. Perception looks weird
61402107 Its reputation as a "concurrency language" or a language for solving "very hard problems", as opposed to a general-purpose language that gives you great productivity across domains. perception only for hard problems
61432681 People often let the original syntax bias their opinion, because they think it's going to be a lot of counting ()'s. Better exposure for tooling that makes this a non-issue would help the adoption of clojure. perception parens
61439406 Tends to be overlooked because of its Lispy syntax. perception parens
61479139 Perception of lisps from outside world perception parens
61504119 The most glaring weakness is it's lisp, but the greatest stength is it's lisp . . . (ha ha) run time performance seems to be lagging behind other language gains over the past two years. perception parens
61507333 being a Lisp, plain and simple. it's hard to convince people it's not crazy to use it. perception parens
61510757 Parentheses freaks the people out perception parens
61554396 A number of collaborators won't consider a Lisp. I would not call this a weakness or a blind spot, but a problem. When comparing functional programming to OO, almost all Clojure programmers focus on OO as commonly practiced. This is understandable and relevant, but It also has a cartoon like feel. Many projects do create complex class hierarchies with no behavior and that should be criticized, but its not OO as Kay, Beck, Fowler or Wirfs-Brock understand or advocate it. The result is an impoverished discussion. perception parens
61615145 Lisp syntax continues to be the single biggest barrier-to-entry to getting other developers to look at Clojure. I find it similar, but to a lesser degree, to some developers' initial reaction to significant white space in Python. perception parens
61710495 most programmers don't understand the benefits of functional programming, and don't want to look at Clojure because of the parenthesis. I think the ecosystem has matured technically and now needs to bring in a wider audience for adoption. perception parens
61442034 It's very hard to read. Between its immature documentation tools and its dynamic nature, I spend a lot more time diving through source code for third party libraries than I'd like. The language would really benefit from a proper "Javadoc" alternative, and the tools that currently exist aren't quite up to snuff. perception readability
62123898 code readability perception readability
61373938 Perception of snootiness perception snootiness
61458990 It requires smarter programmers perception
61509395 Educating developers who aren't familiar with lisp. perception
61897946 Performance / Integration with android's Dalvik VM. Clojurescript as the "Mobile Story" doesn't work on android yet - far from it with regard to native UX. performance android
61357427 It's really slow compared to Common Lisp. Performance Common Lisp
61358601 Performance issues can be troublesome for soft real-time applications like game development. Performance games
61509940 The lack of ability to use co-processors. performance gpu
61405703 There are a lot of people in the mailing list having problems getting Clojure to perform well with multicore problems. Given that this is one of Clojure's big selling points it doesn't feel like these features have been very deeply tested in the same way that, say, the equivalent Java libraries have. performance multicore
61363798 not compiling to native code as Go does performance native
61363954 Difficult to use for games and similar high-performance, real time applications. performance real time
61356785 runtime performance seems to generally be worse than Scala. Of course Clojure does a lot more internally, but it's hard to explain that to someone who has only done OOP. Performance Scala
61356293 Startup times Performance startup
61356317 Startup time. Tooling designed in Clojure (e.g. Leiningen) takes a very long time to start up. Performance startup
61359745 Start-up time and memory use Performance startup
61361914 good debugger, funky error messages, slow startup Performance startup
61362013 JVM starting time Performance startup
61362875 Startup time Performance startup
61363275 Start up time is *still* a killer with a standalone application of any size, with a bunch of libraries. performance startup
61364063 JVM startup time. performance startup
61364764 startup time and overall typical runtime speed, confusing java interop performance startup
61365446 Startup time. Hopefully porting to additional backing runtimes will help with that, though we need to be careful about compatibility and portability of Clojure code to those systems. A compatibility layer may be useful. performance startup
61366144 Startup Speed performance startup
61367162 Startup time and memory usage. performance startup
61367496 The startup time of the JVM. performance startup
61368103 Probably the start-up time and lack of ability to compile to a binary. I would totally write all my command-line utilities in Clojure if it weren't for that. performance startup
61368948 It's partly because of the JVM, but clojure programs are really slow to start. performance startup
61369426 startup time :( performance startup
61370513 JVM start up time performance startup
61371420 JVM/Startup time performance startup
61371948 Startup time. 1.5―2.0x JVM startup time would be tolerable for scripting. performance startup
61375903 Startup time - loading docstrings etc. performance startup
61378384 A weakness about what? About adoption? => A reasonable debugger About mobile? => Fingerprint, memory consumption (unless you think clojurescript) About general use? => Startup time (JVM related) About the language? => Lousy namespaces and many cryptic compiler error messages. Regarding adoption I'm not sure a huge community is desirable though. performance startup
61392770 startup speed performance startup
61395927 Slow start-up time performance startup
61397964 Not very suitable for GUI programs due to slow startup time of JVM. performance startup
61403723 The JVM startup time. performance startup
61408747 JVM bootstrap time performance startup
61413926 Startup time for quick scripts (and I'm not a fan of the various "hot JVM" solutions) performance startup
61417268 JVM memory pressure and start-up time are hindrances. performance startup
61417520 Startup Time. performance startup
61417834 JVM startup overhead, documentation performance startup
61422828 Slow startup time and lack of proper documentation performance startup
61424650 JVM startup time. performance startup
61429592 That damn jvm startup time. performance startup
61435032 Startup time performance startup
61445858 startup time performance startup
61493377 Startup speed performance startup
61505460 Its usefulness in many potential applications is limited by the jvm's startup time. performance startup
61506735 For my usage, the weakest spot is startup time, but maybe I'm just using it wrong. performance startup
61527816 slow start-up time performance startup
61530330 Start up time performance startup
61548472 JVM Prejudice, I used to have such against Java. JVM startup time still sucks. performance startup
61564154 the slow start-up when using the JVM performance startup
61694544 start up time and deployed package size (these are related, and not just the jvm's fault) performance startup
61713933 Slow startup time performance startup
61930880 slow start-up time of jvm performance startup
62120166 Startup time for scripting. (indirect problem) performance startup
61359670 Optimizing tight loops without resorting to Java can be hard. It's often hard to figure out what needs to be tagged (and how) in order to achieve best performance. Performance tuning
61362362 JVM limitiations (slow startup, no staged eval, slow multimethods, lack of value types, no TCO) Performance
61368054 Runtime speed and/or launch speed. Otherwise, it's a good melting pot :-) performance
61372920 Performance. And yes, I know I'm also asking for better Python interop, but there are multiple scenarios where Clojure shows off the worst side of the JVM (RAM and GCs), and where Python is slower but more resource-efficient. performance
61396501 Runtime Speed performance
61400278 Performance is not quite there for desktop/android applications. performance
61407782 Runtime characteristics, in time and space, for some use cases. Mainly hard to embed or deploy (due to artifact size), or slow to start, or consumes too much memory. Usually necessitates using a special or novel host VM, which tends to be immature or incomplete even if it is performant enough. This includes use cases on Android, small computers (e.g. Raspberry Pi), cheap/lightweight virtualized servers, short-lived desktop or command line tasks, etc. performance
61409906 Slow performance compared to other Java-hosted languages, let alone Java, let alone C/C++. performance
61419690 Performance, both in runtime and compiler. It's *good*, but many projects take 30 seconds or more to compile; throws a serious wrench in my dev process. Keyword interning is O(n) because it does a weak ref scan over the whole keyword table. Primitive math is unpredictable. Recur is significantly slower than a java for loop. That sort of thing. performance
61426092 Clojure consistently does everything I need, but not always fast enough. I frequently find the need to refactor heavily-used code into Java. This is specifically in the case of scientific applications (molecular dynamics, robotics, etc.). It may be style, or too much reflection (one can always factor out more reflection), but either a Clojure implementation in C/C++/Assembly or Clojure -> Java conversion, would be nice. performance
61502376 Although it's not exactly glaring, I'd say performance; the rest is all good. performance
61596990 It would be nice if the performance were closer to native Java performance
61613911 performance performance
61903527 performance performance
62030821 Sometimes performance hits strike even with idiomatic Clojure. Hard to predict/fix, require knowledge of underlying mechanisms. performance
61355308 It solves interesting, hard problems at the expensive of solving the boring, easy ones. process
61353736 AFAICT, there is no committed maintainer. Lots of things _could_ be done to improve Clojure, but few are interested in the process, or waiting YEARS for simple improvements to land. Process attention
61356167 Speed of bug/doc fixes in the language, hopefully changing w/ Cognitect. Process attention
61359422 Slow clj.core issue handling (bottlenecks) Process attention
61365755 The appearance of stalling on Clojure the language. There might be progress on tickets (patches, discussions, testing) but getting that into master and getting a release out. Even smaller bug fix releases etc. process attention
61367082 The JIRA development process is very slow-paced. You'll have a long beard until you'll get feedback on some ticket/patch. And even if all is fine, i.e., you have addressed all concerns and comments, you'll usually have no indication wether it will ever hit the master branch and when. The only responsive person in JIRA is Andy Fingerhut, and he does an extraordinary good job (thx!). However, the "deciders" like Rich himself aren't that active. My impression is that they look into JIRA only before they'd like to cut a release, then select a good dozen of recently active tickets, apply their patches, and that's it. Well, that situation is basically the same as last year, maybe it has improved a little, but not enough. process attention
61367431 Mainline development is understandably a slow deliberate process, but some aspects of it are relied on by ClojureScript. Recently this has improved because ClojureScript has reinvented some bits in order to move at its own rate. process attention
61368835 Except for the slow pace of change in contrib libraries (I understand why core changes as slowly as it does), most of my frustrations with Clojure are things that couldn't be changed without the language ceasing to be Clojure (and becoming Haskell, or whatever). The frequently surprising behavior of runtime initialization and AOT compilation has bitten us several times though, and I could wish non-AOT and AOT code were just more _like_ each other. process attention
61374102 conservative approach to accepting patches process attention
61385614 The development of Clojure itself is frustratingly slow. process attention
61565607 slow core library development process attention
61358949 Paper CA and the development process that's quite cumbersome for contributors. Process CA
61362422 High-friction core contribution process. Process contribution hard
61428248 Nothing was exactly glaring to me. The contribution process seems to frequently irk people. process contribution hard
61359029 releases aren't too often, no "real agenda" for next releases, some problems (like error traces/reporting) isn't fixed for a long time Process focus
61368092 Relevance, Inc. process Relevance / Cognitect
61381631 Lack of approachability as a design goal. The core team seems to think that being approachable to newcomers is incompatible with offering full power to experienced users, but admirable projects like Racket prove that this is not the case. process relevance / Cognitect
61389795 The lack of insight into Relevance and Rich Hickey in particular, leading to the glacial pace of development. process relevance / Cognitect
61362001 One coherent place to find acurate info on the language and it direction in the futur. Should be one place with : - reference documentation for every clojure major versions, with examples and remarques - language discovery, first step, download page - commercial support - libraries resources - supported tools Actual web presence of clojure is to scattered around the web. It does not help industrial, commercial acceptance and adoption. Process roadmap
61397520 Until the hiring of Andy Miller the lack of community management but there still needs to be more visibility / feedback on community proposals and what the roadmap. Is there a 2.0 plan? Until Cursive a decent IDE, and the ridic emacs fetish. Now its probably the slow paths that are hard to predict till you hit one and then are hard to profile. Its time to rewrite the compiler. Oh and namespaces kinda suck. process roadmap
61421399 Clojure 2.0 should merge back with ClojureScript and be more internally extensible than the current Java monolith. Clojure-in-Clojure hopefully a reality. Who's actively driving the vision now - is Rich focusing on Datomic? process roadmap
61490705 There are either super advanced explanations or baby steps. Not much in the middle. process roadmap
61360779 Both a plus and minus: Incredibly reserved, methodical and quiet language maintainers (Cognitect) Process
61372404 Documentation. There is a lot of out-of-date information online, and the documentation quality for the core language and libraries is not nearly as good as, say, Python. Clojure has an amazingly powerful story to tell but it is also a somewhat strange story to many mainstream developers. The documentation could tell that story better, and still be simple. The several excellent books out there go a very long way but they are not enough. I do think the strictness of the CA / ticket execution process does hurt this aspect a bit. Documentation is a way for relative newcomers to contribute, but the process is slow, and not particularly simple or easy IMO. process
61375960 Difficulty contributing to the language (JIRA, CA, etc) process
61382259 JIRA and the CA-backed contribution process discourages positive contributions to the language. This has been talked about to death, and it seems to always end with inaction. I'm not asking for it to change overnight, but I wish as a community we could come together and make it less of an ordeal to be part of the Clojure development process. I've seen people's hard work on patches get chucked into the fire, and this is after they signed a CA, spent the time to write the code, followed the process for submitting their change, and waited a year and a half without bugging anyone, only to have it closed without comment. Those people are not going to contribute again, and I think that's a shame. process
61439056 the dichotomy between the official position that contributions to the core are welcome and the fact that they are not process
61447313 Improvements and fixes go in only in case they fix something for cognitect or in case drumming is reeeally loud. (Same story since years despite the efforts of people like Andy or Alex.) process
61462237 Nothing in particular. Would it be kicking a dead horse to ask for Clojure to accept GitHub pull requests? :-) <ducks> It's a great language, great ecosystem, great leadership. I'm happy and am a strong advocate of the language. process
61475468 Clojure seems effective for the very smart but I find a lack of documentation and recommended practices from Cognitect frustrating. E.g. is still a go-to site for me even though it only targets Clojure 1.3.0. Why doesn't Cognitect provide something like this? The hangup of not accepting any documentation or tutorials that don't have the protective halo of the Contributor Agreement is frustrating. There should be an active effort to identify the best docs, tutorials and practices out there (i.e. "useful shit") and collect them under one roof. Source: I can currently only program in Clojure very part-time. process
61536338 "Toy language" attitude - the developers don't seem to care about error messages, backward compatibility between versions (e.g. the change in the meaning of = bit us, and so did the way clojure.contrib libraries just disappeared in one upgrade with just one poorly-maintained wiki page with a list of possible replacements, except in cases where there was no replacement). process
61399415 If I want to write a Python script I can make a file called "" whose contents are "print 'hello world!'". To run it I can type "python" at the command line. To do the same thing in Clojure requires using "lein init", navigating down a couple of directories, editing a file, and then still not being able to run the "script" except through Leiningen. (I could use "lein run" but then I'd have to edit project.clj too.) The process of "installing" Clojure itself has gotten less painful but this barrier to running a script, no matter how simple, makes Clojure unattractive for projects larger than "messing around in the REPL" but smaller than "modestly-sized application". scripting
61616607 shell scripting scripting
61616793 Language runtime bootstrapping takes way too much time, which renders the otherwise desirable scripting story impractical. scripting
61760357 Lack of command-line facilities scripting
61817971 Still too much accidental complexity in tooling, startup speed. I'd like to use Clojure where I use Python and that can't happen yet. scripting
61369825 There is no *good* way to write a multiplatform library. In addition, clojurescript libraries are distributed as jars, which doesn't make much sense. Now that multiplatform is becoming a serious use case I think it is time to update our tooling so that it is not so coupled to the jvm. tools cross compilation
61353929 Tracing/Debugging Tools debugger
61357779 Debugging: in JVM version, stacktraces. Poor EMACS and NREPL integration, and some bad choices made in it. Debugging REPL entered code (no line numbers, so it's lost). Etc. I've been a Lisper since 1978 (sic); I pity those new to it trying to use Clojure on the JVM. Tools debugger
61357780 better/easier debugging and profiling tools Tools debugger
61357840 lack of easy runtime debug capability Tools debugger
61358713 Robust tooling support like java, specially debuggers, profiling tools. Tools debugger
61359402 better and easier debugging and profiling tools. Tools debugger
61359461 Integrated IDE with debugging support - if only IntelliJ supported it out of the box... Tools debugger
61361914 good debugger, funky error messages, slow startup Tools debugger
61362915 Final closing off of tools stories: debugger from all the IDEs/Editors. The filling out of libraries like Friend so that the ecosystem has strong libraries to match the competition. Tools debugger
61363477 Debugging possibilities (instead of println). Error messages. tools debugger
61368613 A lack of a well tested debuggers. tools debugger
61380854 It is bleeding hard to debug at times. Mostly do to lazy evaluation. tools debugger
61381029 The tool set is still too adhoc and primitive: many moving pieces, little support for debugging and refactoring. tools debugger
61385180 Poor debugging and general tool support will continue to hamper Clojure adoption IMO. I love emacs, but I can't limit my hiring process to users of emacs. :) tools debugger
61385195 Debugging Clojure can be a pain in the ass. With its dynamic typing (which can be great) it's sometimes hard to catch subtle errors that the compiler could have avoided otherwise - at compile time. Also, the stacktraces are ugly at best. For beginners not really helpful and sometime even misleading! tools debugger
61387542 Lack of proper, approachable Clojure-specific debugger(s). A real module system. tools debugger
61387959 Difficulty of debugging dense clojure code. tools debugger
61389398 debugging tools debugger
61398265 debugging tools debugger
61407425 Poor debugging facilities tools debugger
61409673 Tooling / debugging tools debugger
61417340 All of these are library issues, not core language issues: 1. Tools for insight into runtime behavior are worse than primitive. Even a decent basic debugger. This is something a Lisp language is expected to do well. 2. Use as a "data science" language not as advanced as should be. Clojure is a great "data" language, so many infer that it might be a great data science (predictive modeling etc) language. Incanter is not very good, yet it's the best we have to recommend to data scientists evaluating use Clojure. There are are a number of good libraries out there but it is difficult to formulate a good case to the working data scientist (who has an R, octave, python workflow), as their excitement fades when they realize that they can't be as productive. However if they are coming from a Java/C/C++ workflow it is better than that for sure. 3. Core or library-introduced constructs for multi-node parallelism. tools debugger
61417476 Tooling needs to be more robust (inspectors, debuggers) tools debugger
61427440 lack of a Python pdb-esque debug repl. (debug-repl and cdt aren't nearly as useful as import pdb; pdb.set_trace()) tools debugger
61430676 Development environment. No debugger (nrepl-ritz never worked), could not interrupt stuck programs in the REPL, 100+ line stack dumps on errors/compile errors, compiler errors only identified one at a time. 'lein test' is great though, really easy to write test suites, and even if the compile-test cycle gives up the power of the REPL, it's kept my sanity (and kept me from dropping the language). tools debugger
61438199 debugging tools tools debugger
61440462 Lack of a debugger, comprehensible error messages. tools debugger
61440609 I'd say the lack of a good debugger tools debugger
61462436 Debugging!!!!!!!!!!!!!!!!!! Debugging!!!!!!!!!!!!!!!!!! x10e100 To get valid breakpoints that work in the code is inconsistent between windows and linux. And if one then throws a couple of machine specific dll's into the mix a whole of of pain seems to ensue. I don't want nor need a all encompassing debugger, but I do want to be able to set/clear break points, look at local stack and local variables through a repl and have that work for both windows and linux. Yes there is ritz, but its not working my windows box at the moment. tools debugger
61468300 Debugging, error messages tools debugger
61516306 *Simple* debugging in Emacs please. tools debugger
61523910 Code debugging, profiling and optimisation. tools debugger
61531345 Better debugging tools. tools debugger
61594065 Getting up and running with a debugger. tools debugger
61723070 debugging system. tools debugger
61890259 Lack of a good IDE / debugging support tools debugger
61910185 Debugging, error messages, &c, could use a cleanup pass. tools debugger
62038628 debugging tools debugger
62114501 Debugging facilities seems to be limited to println. Making sense of stacktraces can be difficult. tools debugger
61615203 Too complicated java-esque namespacing and dependency resolution tools dep mgmt
61372153 Lack of generally accepted solutions for deploying and ensuring reliability of more complex systems. This includes configuration of component and a mechanism for packaging and running them that goes beyond lein uberjar or lein run. tools deployment
61446796 Built-in ability to add new project dependencies without restarting the JVM. Warnings if there are updated versions of the dependencies available. Switching between Emacs (due to my lack of Emacs knowledge) and LightTable (due to not having all the features I require at the moment). It would be nice to have a full-featured dev environment for Clojure that matched and even succeeded Visual Studio in features. tools deps
61905657 Emacs :-) tools Emacs
61354587 The credo of Emacs as "the one true way". For a newcomer to the language, that's an immense cognitive load in addition to learning the language. Tools Emacs focus
61356468 lack of IDE options/emacs centric community Tools Emacs focus
61357049 *IDE support* Emacs is good, but it requires one to be an Emacs expert to effective. Eclipse/CCW either doesn't cut it so well, or it's not so well documented how to use it as effectively as one would in Emacs. Tools IDE
61358253 ide support Tools IDE
61360460 Solid IDE support, and respect for IDE users in the community Tools IDE
61368475 Tooling is a barrier to entry for developers used to IntelliJ/Eclipse type IDEs. Yes there are lots of options, but none is clearly the best. tools IDE
61368548 IDE on par with static-language IDEs. Lack of static typing helps Clojure be an amazing *lanuage*, but the language itself is only a part of the overall dev experience. tools IDE
61368897 The only real improvement I'd like to see is a good IDE, preferably something that isn't based on Eclipse. tools IDE
61407218 One major area of deficiency comes in Java interop IDE intelligence. Eclipse Java editing, for instance, provides comprehensive lists of fields/functions/methods and associated Javadoc materials as part of the code completion process on an object in the source. Opening the documentation separately becomes largely unnecessary, since the salient majority of information useful for invoking a method is accessible with a Ctrl+Space. The facilities for resolving the class of an object statically naturally make this capability more tractable to implement in Javalang than in Clojure (where type annotation is optional, and methods will be resolved by reflection if necessary), but it would be astronomically helpful to include comparable information in a code completion hotkey for annotated Java object references. I don't even know who to suggest this to, though. tools IDE
61436366 Tooling/IDE Integration * symbol renaming * var extraction of inline functions * moving functions/vars to another namespace * better errors/stacktraces * test integration (e.g. junit) tools IDE
61437752 Eventhrough a perfect IDE for a dynamic language seem impossible, but we really need a good enough one. I use emacs for clojure programming, but for many other coders, emacs seems hard to marster. tools ide
61442785 superior IDEs tools IDE
61476178 To really gain mainstream, IDE editor support must be not only better, but entirely different. LightTable address ease of use well and has great dynamic evaluation features, but it does not at all address the code maintenance the mainstream static type people are used to (which is really orthogonal to the first one). What really is missing is smart code organization and refactoring tools like e.g. Refactoring Browser in Smalltalk. While conciseness and expressiveness was appreciated by anyone I showed Clojure to, none wants to find the function definition and refactor using file search and text search/replace. Indeed, Java with Intellij/Eclipse is vastly superior in this respect and the main reason I am unable to sell Clojure to anyone in corporate env. at the moment. tools IDE
61524802 Lack a good development environment, i.e. an extensible editor that's easy for beginners to pick up, easy to extend, and powerful enough to work across larger codebases, where the ability to quickly and easily locate function definitions etc is key. A decent built-in debugging tool with breakpoints and step-in/step-over/step-out would be awesome too. tools IDE
61609734 Integration with modern IDE's is anemic and a joke. tools IDE
61614749 Lack of IDEs with integrated debugging tools IDE
61619077 The tooling is the problem. Not everyone uses terminal/emacs for programming. The integrated IDEs like LightTable free up from a need to setup everything manually - it's not open source yet, and not finished. Counterclockwise is fine but still feels fragile. tools IDE
61707795 lack of first class development environment tools IDE
62027717 Good integration with graphical IDEs tools IDE
62032117 I love Emacs. I've been using Emacs since 1991. I can't find people who are Emacs experts who are also interesting in functional programming or know Clojure or are familiar with Java or the JVM. There needs to be a productive dev environment for Clojure that is less intimidating than CIDER/nrepl.el + Paredit. tools IDE
61424638 Having a workbench for developing several projects simultaneously. But jig is a tool that's addressing that. tools large projects
61436409 leiningen not allowing local libs :( i know thats not a clojure problem, but still... tools lein
62035542 Lack of a linter tools lint
61354838 Decent dev environment with refactoring. Come from Java/Eclipse background. Tools Refactoring
61359608 The tooling. Clojure still lacks good IDEs that provide basic refactorings and automatic generation of namespaces/imports. Tools refactoring
61583670 Difficult to do refactoring. tools refactoring
61848276 Refactoring using any IDE is tough. I ran into an interop problem when using a Java library that returned instances of a private class. I had to figure out type hinting. tools refactoring
61361743 lack of good REPL/slime type integration in anything but emacs, options in other editors are poor at best Tools REPL
61359894 Lack of static analysis tools. Tools static analysis
61413968 Windows ecosystem is second class tools windows
61354169 Complexity of setting up a development environment Tools
61360120 development environment documentation Tools
61361319 Environment - though that it changing. I think that Scheme has done it so well with Dr Racket. We have a few of these environments that are interesting and I am hoping that the Clojure community adopts one of these as an official platform and develops it out. That would make Clojure unstoppable. Tools
61365288 editors/development environment (take a look at something like DrRacket) tools
61367965 Getting up and running with an editor requires far too much prior knowledge. If you're not using Emacs you feel like a second-class citizen, and getting up to speed adequately with Emacs takes far too long. I didn't want to learn about Emacs package management on day 1, but I was forced to. Coming from Vim (my preferred editor), the landscape was too variable. Vim-clojure pushed us towards Foreplay, which became Fireplace, but the functions aren't all there, and you need to install several different packages to get it to be useful. But then the packages can interfere with each other, and things can be really hard to configure to make them work. Even then, how do I find all the appropriate packages, and how do I keep versions in sync, so that they play nicely? Over time I ended with less functionality than I started with, which is why I tried Emacs. Counterclockwise looks nice, but the Eclipse system can be far too heavyweight unless you're in a large project. Emacs/Vim can both be launched quickly to inspect/modify code, but Eclipse will take a minute or more to start from scratch. Lighttable looked nice in presentations, but I've yet to get it to talk to a REPL, despite multiple attempts. Embarrassing as it is to admit, I still rely far to much on saving to disk combined with a command line REPL with copious re-use of (require ... :reload-all). Emacs/cider has allowed me to move to a more integrated system, but the learning curve to get there was more than it should have been. tools
61370414 for me I still haven't figured out the right tooling. I use Eclipse + CCW, but I don't particularly love it. tools
61374870 Lack of decent developer tools. tools
61375271 Editors in general is something I've found to be a weakness. Especially when you want to use Clojure and Clojurescript at the same time. Switching editor is also a high cost in terms of time. tools
61382411 The tooling around Clojure is ok, not great. In the long term, everyone suffers for the lack of official/sanctioned tools for setting up environments, perf testing, and code analysis. Everyone seems to have written their own Clojure parser/analyzer, with little thought to keeping such tools unified across implementations and Clojure runtimes. tools
61383641 It hasn't sufficiently capitalised on the ease of real-time programming by integrating with emacs/vim as well as lisp has. Because it is JVM only it is difficult to argue for production usage where other languages will compile natively. There is also a lack of acceptance in the workplace. tools
61389592 The tooling. tools
61391382 Tools, and tool support for dynamic languages to match static languages tools
61397331 Great tooling support. tools
61399032 - no good ide - difficult to refactor - no two pass compilation (helper functions on top, real meat on bottom -- opposite of expectation) - no best practice for code layout - no clear multi-project support tools
61402990 Tooling. tools
61408619 I think that the editor story needs to be better. I live in the REPL as much as possible, but as a Vim user I feel like I am either limited by the tooling or just don't know how to be effective. I don't know how to reload an entire namespace into the REPL from Vim, switch namespaces without doing it wrong, etc. I Kickstarted LightTable and have tried to use that, but frankly it was too confusing last time I fired it up. Maybe we just need better documentation/walkthroughs. To be clear, I can edit-compile-run just fine, but what I like about Clojure is the interactivity and so I have high standards there. tools
61411313 Development tools. Leiningen is great, and nREPL and CIDER together are a strong start; but for all the elegance Clojure has on offer, chasing down errors is still messy, with a suboptimal signal-to-noise ratio. tools
61412631 Tooling compared to traditional Java tools
61418465 It is way too difficult to get an easy-to-use Clojure development environment up and running. I've tried 4 or 5 of the options, and all are poorly documented and have very steep learning curves. Part of the issue is that you can't just put some code in a file and use an interpreter or compiler on it, like you can most other languages. You have to set up a project, etc., which just makes it a pain for both new users and experienced ones alike. tools
61419744 The development tools are lagging behind... Not that Leiningen or emacs or ccw, etc are not good, but there's a lot of work to customize one's environment, worst in teamwork. And here again is missing documentation (well not to be searching around), not on pieces but to put the whole in a coherent state. Some libraries are lagging too or cross dependencies give difficulties. A local cache for external libraries to be able to work offline... tools
61425492 Developer creature comforts. This is being largely addressed but if we really want to take over the world, we've gotta get better at this. :) tools
61435162 Editors and a "series" of recommended toolchains. Even a simple comparison and contrast of 'framework X vs framework Y' especially in the Web/Clojurescript space. tools
61445365 tooling tools
61461889 tooling, troubleshooting headaches tools
61472598 Clojure is wonderful at handling and provided ways of thinking about state in an application. This then leaves the meta-level of state accumulated in the development environment. This is being addressed somewhat by tools and best practices put forward by the community but it still seems a weakness. In general there are great resources for learning how to *program* with Clojure. There is much less with respect to learning how to *develop* with Clojure - manage projects, namespaces, documentation practices etc. This is particularly true for those coming to clojure on their own and not as part of a team or company adopting Clojure. tools
61487025 Tools and/or infrastructure support for assembling & deploying anything other than toy or small programs. tools
61499770 Tooling tools
61513289 Tooling - no equivalent to "find references" a la Java IDEs. tools
61520856 I'm interested in RAD tools. Things I can develop robust apps with efficiently. The lack of a SQL/Relational DB ORMs pains me. Coming from Python/Django it seems like a glaring omission blocking efficient app development. I've also never bonded with an IDE which gives me rich debugging tools: friendly stack traces, stepping through code, updating variables. tools
61525916 It's not the easiest language to get going with. If you're already an Emacs/Vim guru, there's simple plugins to get going with. But if you're not of that type, there's no easy path in (learning Emacs as part of a new language is a non-starter for 99% of the population). tools
61592131 setting up Emacs, swank, slime tools
61596055 Emacs + cider/nrepl seems to be the common environment for Clojure developers. This setup is not so smooth for newbies to learn. I am optimistic about the Nightcode IDE. tools
61596835 find references in a large code base tools
61928139 Developer tools. General inertia about using language that looks non-C like. tools
61940670 so many editors, web-frameworks/stacks tools
61962354 Tooling. It's improving immensely, but most people don't want to use Eclipse (much less emacs), and the missing debugger's a show-stopper for most people I've run across who are willing to try to look past the horrible college class they took using scheme. tools
62117110 Tooling. On one hand, there are superb build tools, like Leiningen. On the other, I'm still using Vim with with lackluster Clojure support and println to debug. tools
61360032 Lack of good type system means less fun with monads. Types No monads
61355144 Data type definitions. One has to look at the origin of the data in the call chain to be able to figure out what it actually is (e.g. what keys a map should contain). There's active effort to this direction though. Types
61358968 For me it's the lack of static typing when the project becomes bigger. Always force myself to better define protocols between modules. If I don't, I'll pay for it in the long run. Types
61364869 unhelpful errors or stacktraces depending of the environment (nRepl with Emacs or not etc.), dynamic typing for big projects, records and maps are similar but not identical (can lead to surprising problems) types
61372150 The dynamic type system is flexible but has trade off.Some issues can't be found until application runtime.And we have to write many unit test cases for our endpoints. Clojure's source code static analyzer is not good enough,i think maybe someone could migrated findbugs in java to clojure,because clojure generates the same byte-code with java,but i am not sure it can be. types
61385195 Debugging Clojure can be a pain in the ass. With its dynamic typing (which can be great) it's sometimes hard to catch subtle errors that the compiler could have avoided otherwise - at compile time. Also, the stacktraces are ugly at best. For beginners not really helpful and sometime even misleading! types
61419888 Its lack of types is its strength and weakness types
61429073 Parenthesis paralysis, lack of infix math notation and weak type enforcement keep it from adoption. types
61435245 Official support for optional static typing. Android. types
61493708 Personally, I'm a fan of type safety, which no dynamic language has. types
61531857 Lack of a static type system (core.typed is a nice start but it's not quite there yet ...) types
61534385 In my oppinion dynamic typing is a strength, but it also makes it hard to sell Clojure to old Java/C#/C++ programmers. types
61690919 I'd like some kind of gradual typing ability. Maybe Prismatic Schema or core.typed would work for that. types
61826923 Static type system, though my typical projects - mid-sized web apps - are feasible with dynamic typing. types
62028226 static typing a la ML or Haskell, but I doubt that can change at this point. Typed Clojure may be nice but can't provide the same thing. types
62033048 Lack of static typing. It makes it hard to understand and use 3rd party and our own APIs. And it results in bugs being introduced that would have been impossible with static type checking. types
62083878 Well-defined record structures (including types and sub-structures) could help with domains dealing with complicated data models. I think Prismatic's Schema is on the right track for this, but having defined record structures in the language, and widely adopted, would eliminate a lot of the headaches of sharing complex data structures. types
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.