Bytøpia

Voted for twice more than for other contenders, type checking clearly interests many Clojure users. People enjoy core.typed and Prismatic/schema and want them in Core, extended, improved and nourished. While some respondents would prefer a strict type system, absolute most voted for optional one that wouldn't stand in the way.

Answers grouped under this category stated that they would like to see a special production build mode that would have leaner runtime, apply tree-shaking and omit the compiler. It is something similar to what projects Oxcart and Skummet are trying to solve. Respondents report that faster start-up would make it possible use Clojure on mobile platforms, in scripting and generally make the development more pleasant.

A usual guest in annual survey results, it never gets old. It has been an issue for me at the beginning, before the Stockholm syndrome kicked in. Anyway, CIDER provides much better stacktraces, and does its best to hide the irrelevant parts. You should certainly try it if you still don't.

This became an issue right after ClojureScript had been released. Users want a way to unify libraries so that they are usable from both Clojure and CLJS. Tools like cljx might help, but they are still hackish compared to what can a native solution provide.

Other tools mentioned are mostly profiler and other IDE stuff (refactoring), but debugger is still #1. While several projects exist that bring debugger-like experience (I remember ritz being the one), anything like Eclipse/Visual Studio debuggers suited for Clojure is still missing.

By new runtimes people mostly mean targeting native platform and LLVM. Erlang VM also occurs a few times.

Surprisingly enough, this is quite high in the list. Users want better namespaces: first-class, composable, immutable, parameterized. "Modules" are often mentioned as a substitute.

Apparently, basic Java try/catch approach can't satisfy everyone. People often mention Common Lisp's restarts as being an exemplary error-handling mechanism. Perhaps, Clojure can learn something from it. In the meantime, there is ribol.

A whopping 211 answers mentioned some or all of those. Maybe it is not very fair to unite all three under the same flag, but that's what many respondents put together — awful error-reporting and hard debugging. Perhaps, if stacktraces were more informative, the need for debugger would be less urgent, and vice versa. This problem occupying the first place shows that while Clojure is all "simple", "easy" is what troubles regular users most.

A few years ago Rich explained that more informative error messages would cut down performance, so there is a trade-off. But most macros (like ns) could be slightly more intelligent about wrong inputs without any performance loss. go macro is another one that gets complained about a lot, its stacktraces being completely out of this world.

CIDER has been getting a bad churn lately for being unstable, and it is reflected in the answers. Recently Bozhidar performed a huge rewrite, adding new features along and making CIDER even more awesome. Unfortunately, this also resulted in a period of instability. I think the main problem here is Emacs packaging system which doesn't allow fixing package versions, and also the fact that CIDER and cider-nrepl middleware have to match. When anything goes wrong, people usually try to update both to the latest version, which might contain recently added and thus insufficiently tested features and all users become unwilling bleeding-edge testers. Regardless of what happens at the moment, you have to give Bozhidar credit for making CIDER what it is now, and what Swank/SLIME could never be. Just put up with CIDER a little until things settle down, and anyway Mr. Batsov is always rapid at answering issues on Github.

Users would love to use Clojure more if it wasn't so slow and large. That's not news. As I've mentioned earlier, startup time (and memory consumption) can be solved by lean compilation, although some users want these characteristics for dev environemt (REPL-enabled) as well. A way to improve the performance is non-obvious, but native compilation might help.

There were different complaints about documentation, here's the list of the most common ones:

• Libraries are poorly documented. Inline/API docs is not enough documentation.
• There is a lack of tutorials and other prose documentation.
• Since the language moves forward very quickly, the existing tutorials become outdated.
• Learning curve is too steep, it is hard to find proper docs to get started. Also, related to shortage of IDEs.
• Best practices should be more apparent. People are lost in the sea of possibilities when they try to do something new and so powerful as Clojure, so they need to be told how to do it, at least at the start.
• clojure.org is simply bad. When it could serve as a tool for better adoption, pointing beginners in the right direction, serving the latest documentation, showcasing the best libraries it does virtually none of these.

While I personally can relate to some of these, some complaints are somewhat surficial. There are a lot of tutorials being written every day if you follow Planet Clojure, for instance. There are IDEs for beginners — like Nightcode and LightTable. API docs for Clojure itself are also present — on ClojureDocs or Grimoire, whichever you like more.

The problem with documentation here is that it is too distributed and doesn't have APPROVED stamp on top. Beginners want to just type Clojure in google, click on the first link in their browser and be streamlined through the whole process of learning basics, however one-sided that might be. Teach them first, let them decide later.

In his talk Design, Composition, and Performance (Oxford comma) Rich Hickey compares learning a technology to learning a musical instrument. Since one learns to play by hours of repetitive practicing, he argues, learning the technology doesn't have to be easy. While amusing, this analogy is dangerous. Music is art, programming is work, in art there is a certain added benefit from how difficult it is created, in the industry noone gets paid because his tool is unwieldy and takes 10 years to learn properly.

Again, couple of reported issues are grouped here:

• Some libraries are missing (data processing, machine learning etc.).
• Some libraries could be better.
• Libraries over frameworks approach doesn't work.
• Clojure could have a better standard lib (like clojure-contrib).

Users complain about the absence of frameworks a lot. The "composable libraries" solution makes sense, but only if you: a) know what every library does and should be doing; b) know enough to be able to prefer one library over another. People loathe frameworks because they make decisions for you, but apparently many developers still love them because otherwise you must make these decisions.

Same for the standard lib argument — there are plenty of libraries, but how do you know which one to use? Especially as you begin learning something, an authority that tells you what to do and what to use is beneficial.

As always, respondents express concerns about Clojure's limited adoption and difficulty to find employers/employers. Some directly complain about insufficient marketing of the language. People want an alluring facade, more success stories, killer apps, convincing arguments for adoption right on the front page. Some wish Clojure had an evangelist company like 37signals or Typesafe. Of course, Cognitect is a company like that, and Datomic qualifies as a killer-app, but their work could be more famous in the outerwebs so that pointy-haired bosses are easier to convince.

A sufficient number of people consider Clojure to be better off JVM. There always have been some grief in the community for JVM being the host, especially among those who haven't used Java before. The compiler still being written in Java is another annoyance, and those who tried modifying Compiler.java have a hard time sleeping at night.

This one is interesting. While finishing the list with relatively small number of complaints, it seems to be the primary gripe with Clojure community and Cognitect in particular. Respondents dislike the "non-open-source open-source" model of Clojure development, where one must sign a CA and go through hoops to submit a small patch. No one likes JIRA. No pull-request policy discourages contributing. While Leiningen is an absolute standard, Contrib projects continue to use Maven.

I can see where the dissatisfaction is coming from. Clojure isn't clearly designated on the "hipster"-enterprise scale. It has many qualities of the young language (lack of polish, limited ecosystem), but at the same time tries to be serious and enterprisy about the way it is developed. This spawns the confusion. People either put up with bugs and shortcomings if they feel they can directly fix this, or they eat what's given but then it should be good.

Here are some problems voiced by survey participants which weren't common enough to be measured quantitatively:

• Segmentation between Clojure and ClojureScript, lack of specification for different runtime implementors.
• "Arrogant" and "elitist" community.
• Focus on new features instead of fixing old known problems.
• Clojure evolution vector makes it feel more like an inside project of Cognitect which they decided to share with others, rather than a solid general-purpose language.
• It is unclear how to write and structure large systems in Clojure, given there are no best practices and examples of such systems.
• Stability has been a concern for a few people.