Daniel Compton

Cognitect have recently released the results of their State of Clojure Survey for 2019. For the last three Clojure surveys, I have reviewed the free-form answers at the end of the survey and tried to summarise how the community is feeling. This year I’m repeating the exercise, keeping the same categories as before. If you’d like to see all of the comments, I’ve published them in rough groupings.

Some comments have been lightly edited for spelling, clarity, and brevity.

Update: Alex Miller has posted a few responses to some of the comments I highlighted below, and some suggestions for the next steps that people can take to help.

Error messages

Error messages have been a top complaint in Clojure for a long time, I think since the very first survey. CLJ-2373 introduced improvements to error messages in Clojure 1.10. A number of comments complained about error messages this year, but none of the complaints mentioned 1.10’s changes. Given that 1.10 was released on 17 December 2018, and the survey ran from 7-22 January 2019, it seems likely to me that many of the people complaining haven’t tried the latest improvement to Clojure’s error messages.

• I appreciate all the work that’s been done in improving error messages. Thanks to Alex Miller and others!
• Thanks for all of your hard work on Spec and the error messages in general (often caused by minor typos).
• 1.10 alleviates most of the problems I found with error messages. Since this was my single biggest concern I had with Clojure, I just want to say thank you for listening!
• Just give me the Clojure filename and line where the exception happened, please. I beg of you.
• Better error messages. Please!
• Great to see the improved error messages in Clojure 1.10 - it was my number one issue in all previous Clojure surveys, but not this one :-)

Spec

Spec has been around for two and half years, but is still in alpha. A number of comments referenced Rich’s recent Maybe Not talk about coming changes to Spec. It was great to see Rich putting in to words some of the problems I had felt. It feels like the community is in a transitional phase with spec, where people are still not quite sure where things are going to land.

• Clojure spec tooling would be nice! Because it’s hard to learn and visualize–and it’s not obvious how to integrate it with normal deftest tests. It has a massive amount of IDE integration potential though.
• I’d really love spec to feel a little more complete. … I’ve got a lot of love for spec as a project and use it heavily at work, but I feel it’s shadowed at the moment by some ambiguity about what changes might be on the way.
• Spec has great potential, but really bad UX. If you are new to Clojure it’s very hard to figure out what’s wrong. Spec made Clojure errors worse.
• Spec should have better tool integration and more static analysis facilities.
• Really excited to see the direction spec is heading, can’t wait to see the next iteration.
• Thank you again, for all that you have given to us. Looking forward to the improvements in spec from “Maybe Not?”! I am certainly feeling the pain points they address, and currently work around them by generating heaps of variations on essentially the same spec per fdef.
• I couldn’t put my finger on it, but it always felt a bit awkward to use specs and had to juggle the spec and what the spec meant at a particular point in time during the flow of my software. Thanks Mr. Hickey for the presentation during Conj, it finally makes sense! I’m looking forward to the next iteration of spec.

Docs

Documentation has continued to be a sore spot for beginners. API docstrings were often cited as being too hard to understand, instead people preferred to see examples at clojuredocs.org. The documentation at clojure.org has grown this year with a number of great guides added, particularly Programming at the REPL.

• Concerning docs, I’m seldom able to really make use of the Clojure API docs. Since examples help me more to understand what a function does, I rely more often upon the examples provided by the community at clojuredocs. However, the quality of the examples vary and it would be helpful if there was a set of curated examples.
• Clojure is great, but the main website, docs, examples and tutorials are not good. I would invest time in improving it as it has become a barrier for the language.
• I wish we had a better documentation generator and a better culture of documentation. I really miss the documentation in the Haskell ecosystem (and five years ago, I never thought I would be saying that!). For example, the Haskell community generally expects detailed documentation of data structures, including detailed asymptotics, e.g. Data.Sequence. This complaint extends to many of Clojure’s included features, too. Headline features like STM have incredibly sparse documentation (about one printed page with the semantics only hinted at), so I’m left guessing at what I can actually do with these things.
• The beginner support is exceptionally good. I think I would appreciate more intermediate to advanced support, in the form of books, courseware etc. to carry through to advanced Clojure.
• I love Clojure. The docs are phenomenal. The improvements to the ClojureScript site and getting started and the CLI tools have been huge.
• As a beginner I really struggle to understand the api docs. I tend to use third-party websites more often.
• It would be great to know things like when to use a record vs a map. Intermediate guides would be nice. Also a guide on effective idiomatic Clojure like golang provides.
• Please work on improving the ease of use. The doc strings for the core language are third rate, poorly written, cryptic and unhelpful. The error messages (although presented more nicely in 1.10) are still the same terrible error messages as they have been for years.
• I’d ask for more examples in documentation and provide more tutorials like Scala School or Elixir School for Clojure, for newbies like me.
• Beginner experience still needs more work. Please consult with first-time programmers and teachers who teach them.

Startup time

Startup time has been a perennial complaint, and there haven’t been any major changes here.

• This long-standing issue of startup time + poor runtime performance (out of the box, without tinkering) + insanely high memory usage is becoming the major drawback of the language for me (and us). We are planning to move to a faster language (probably Rust or Go).
• I would like to use Clojure (not CLJS) in AWS Lambdas for a side project but the painfully slow startup time prevents me from doing so. Improving startup times will do more than just improve developer happiness, it will make Clojure a much better tool for serverless computing.

Marketing/adoption/staffing

Clojure continues to grow in business adoption, but hiring developers has been one of the top three things preventing people from using Clojure for the last three years. I’ll add that one way that companies could address the mismatched supply and demand of Clojure developers is being more open to remote workers. Update: Alex Miller also suggested training people in Clojure, which I thought about when preparing the post, but forgot to include in the final copy.

A new option in the survey this year was “Convincing coworkers/companies/clients”; it was ranked number one in preventing people from adopting Clojure. In my opinion, this is a significant issue to be addressed if Clojure wants to grow its market share further. This probably needs more research to find out what the barriers are to convincing people. Elm is proof that exotic languages can be adopted widely, we should learn from what they’ve done.

• We’d all benefit from wider Clojure take up. I worry about the view from the outside looking in. Why is it not attractive to more?
• My biggest problem after one year of intense Clojure learning/coding is to find a Clojure job as remote (because there are zero Clojure jobs in Taiwan). Regardless of how good I am at writing functional code, finding a remote job (outside of the US) is hard.
• Very passionate evangelist 5+ years – It’s surprising how hard it is to have some folks even consider Clojure. Rubyists are particularly baffled: “ok what do you mean REPL driven – we have pry!”, etc.
• I co-founded a startup company and we picked Clojure as our primary language and are very happy with the decision. A nice note is that almost none of our hires knew Clojure before, they all learned it quickly and like it! I don’t see a lack of Clojure talent as a concern at all.
• Clojure is thoughtfully designed and stable. It’s a dynamic, functional lisp that can actually be sold to the bosses (A sentence I never thought I would write).
• Clojure has a great community and great technology but it would be super helpful in selling the language if there were more efforts put into marketing the language and perhaps having “blessed” solutions using Clojure from Cognitect; similar to what Lightbend does with Scala.
• Thank you for all the hard work you all have been and continue to put into Clojure. We’ve built our entire new startup on Clojure, and was able to hire an amazing team within just a year by tapping into the local, tight-knit community.

Language

There were again more suggestions for improvements to existing language features, or development of new ones.

• Please, take a look once again at Dunaj Project or similar ideas. I believe that the community still have many great ideas which could be adopted by Clojure and wouldn’t bring up any breaking changes. And we need better IDE for sure.
• Please spend time improving clojure.test.
• When I dream, I dream of seeing a slime-style backtrace in Clojure.
• ClojureScript namespace definition <-> :require <-> macro & reader conditionals - and how these interact with each other is seriously non-trivial; especially so for macros you intend to use in Clojure too. Simplification there would be welcome, if possible.

Language Development Process

2018 had a lot of discussions about Clojure’s development process, and the relationship between the core team and the community. I was very curious to see how widely those feelings were reflected in the free-form comments from respondents. After compliments (~230), this was the most common comment type, with ~70 responses (positive, negative, and in-between) on Clojure’s language development process (out of 563 total comments). While many people had issues with the development process, there were also many people who were supportive of how Clojure is currently developed.

• Grateful for the careful stewardship of Clojure and ClojureScript by Rich Hickey and Cognitect.
• Clojure has strong opinions on how software should be built. It needs to keep those strong opinions as it’s these opinions that differentiate it and make it attractive. Keep up the great work!
• Clojure is Amazing and you guys do a FANTASTIC job!!! Ignore the critics and keep doing things just like you have been. Thank you for this wonderful language!!
• Closed core development and disappointment with spec have made made many friends leave Clojure/Script last year. Let’s make 2019 better.
• I love Clojure, and an extremely grateful to Rich, Stu, Alex, etc for their continuing stewardship and work of this fantastic gift. With respect to recent kerfuffles about community involvement, I simultaneously understand and respect Rich’s position, and I am also concerned that some very respected Clojure developers who have contributed a lot (IMHO) feel disconnected and may be drifting away from the community.
• About the governance of Clojure by Cognitect: thank you all! You’re doing it right.
• Managing expectations in 2018 is about 10 years too late. Please give a signal that the core team recognises that, and also how much the community is worth to Clojure as a language before dismissing any critics to the (previously very unclear) contribution/lifecycle process.
• I love the principled stand taken by the clojure/core team about silly arguments erupting in the “community”. I really appreciate that the core is so well thought out and there is a valid resistance to adding “stuff” in there.
• I appreciate Alex’s insights into the Clojure development process, and what he’s working on. I also appreciate the all of the core team’s work that makes Clojure such a great language to use!
• Thanks for recent improvements inline with community wishes. Still makes me sad we don’t have a bigger core team utilizing the skills of (some) of the community that could do things like e.g. actively improve core.async.
• Clojure is a wonderful language; however, we are becoming worried about the future prospects of the language because of the way that Cognitect handles community feedback about the direction of the language.
• /2018 was the year that Rich finally explained how he felt about the open source community around Clojure. For many this was disappointing, but I’m glad that he finally explained how he felt, because at least it is now in the open and people can make decisions with full information. Five years ago, Clojure could afford to lose key contributors because the language was growing and new people were coming along. Clojure is now at a very different place and position, and it’s no longer growing at the same rate, or has the same mindshare. I’ve invested many years, and lots of time into the Clojure community. Up until this year, I thought I would have a long career with Clojure, but I am starting to look around at other language communities for ones that are a better fit for my values.
• Even though I agreed with the substance of Rich Hickey’s “Clarity” gist, it is concerning to me that some of the more prolific library maintainers are leaving the community. I’m sure that had it been me, I would have responded even less graciously. Still, there’s an element of community management that goes beyond just being correct.
• After using Clojure professionally for 7 years, I am hedging my bets by involving myself in the Rust community. While Rich’s comments may be lauded by the greater online community, it has had a large impact on my personal consideration on the state of Clojure. … But, as a member of the community, my concern is that the user base of Clojure cannot grow larger without this concept of ownership changing. This conflict, at the end of the day, is a conflict between what my hopes for Clojure were and the interests of Cognitect … But it seems that Clojure has remained what Rich originally intended it to be. … The conflict is simply that, for some reason, I had assumed my interests were in line with Cognitect’s. It has become clearer, year after year and especially this year, that this is not the case. It’s very likely this misunderstanding is a mistake on my part. Looking back, I see no reason that I should have assumed this other than it is generally the trajectory of most languages focus on growth. For this reason, I will likely exit this community as many others have. I don’t have any hard feelings or regret being part of it. I am very appreciative to all of the hard work that has gone into Clojure and regretful that I did not contribute nearly enough during my time writing it.

Community

People seem to mostly enjoy the Clojure community, but others have had negative experiences, often citing an elitist attitude from some community members. Losing the history from Clojurians Slack came up several times. I’m not sure if everyone is aware of the Clojurians Slack Log?

• … the community has been aggressive/hostile from our experience.
• Love the community. Everyone has been really helpful. I wish it was more diverse and wrote more stuff down. A lot seems to get shared face to face which is great, but makes a really high barrier to entry.
• I’m a bit worried about the long-term viability [of Clojure]. I wouldn’t be so worried about the language and ecosystem not being friendly to newcomers, it’s clearly distilling many years of software practitioner’s experience and thus is opinionated.
• The only bad/ugly part of the Clojure ecosystem is the use of (unsearchable)Slack as the main knowledge base.
• I really enjoy this community. Despite the occasional war of words, generally it seems to be filled with helpful, deep thinking people who are fun to interact with. If we were known for one thing only, I’d like it to be that!
• Thanks so much to the Cognitect team and everyone who helps to make the Clojure community better. I understand that people can be very vocal about the things they dislike and not so much when it comes to appreciate the things that work nicely. Being able to use Clojure professionally to build software that solves problems is really exciting and I’m grateful for it.
• I suggest moving off of slack to a more accessible chat system. Losing history is a bad thing. Check out discord or matrix or gitter or mattermark or any other number of tools made for this purpose.
• I’m concerned that there is too much of a disconnect between the core developers and the wider community. … I think it would be great if the core acknowledged some of the work of Clojurists Together. I think the new clj-commons organisation is a great idea and I’d like to see it better promoted and supported.
• The tone in the community has changed. I think this is very sad.
• The community and the prominent people around it are OUTSTANDING. It is really something to behold. This was my first motivation. I am staying for the good language and tools and etc. but the people behind it are definitely the main treasure here.

Libraries

People are still looking for a curated on-ramp into Clojure web development, a ‘Rails for Clojure’. There are a number of frameworks and templates here, but they don’t seem to be hitting the spot. I’m not sure whether that is because of limited mindshare/marketing, limited documentation, or the scope and quality of the frameworks. Having used Clojure for many years, I no longer find it difficult to find and assemble the pieces that I need for projects, but I definitely remember finding this being difficult when I started. Data Science and ML were places that people saw a niche for Clojure. Several people hoped for improvements on core.async, it still has a number of rough edges.

• I would love to see a way to get open source tools, such as Cider, sustainable support. I’m worried about all you open source maintainers getting burned out and not creating these awesome tools. I don’t know what this looks like yet. [Ed. I’ve got just the program for you]
• I know that Clojure promotes a build-it-yourself type of mentality, which is nice, but it would be great if it had standard implementations for things like webapps (auth, security, etc.) that were leading the way for alternatives to follow. It’s ok to be opinionated, if it works properly.
• One huge opportunity that is still being missed is the field of data science – Clojure(+Clojurescript) has the potential to become the best platform for data research ever. In that field, more than others, it is important to be beginner-friendly.
• Clojure needs a Rails-like “killer app framework” that provides novices a training-wheels included opinionated approach to building applications with Clojure. The roll your own / pick your poison approach to Clojure is a barrier to many.
• core.async could use some love with closing long-open bugs and documentation on best-practices and how to build bigger systems with it. Or maybe it just needs to be officially deprecated? As an outside observer, it feels like it’s in limbo by the clojure-core team. Either way, we’re currently using Zach Tellman’s manifold abstractions a lot to great effect.
• I much prefer the library over framework approach taken in the Clojure community, but I do miss the rapid development which RubyOnRails allows, i.e. conventions.
• … I think a curated collection of recommended third party libraries would help a lot of teams.

Other compilation targets

People have been experimenting with the Graal compiler to produce static binaries without needing a JVM. At this point that seems like the strongest option for people wanting to use Clojure without the JVM. Better Android support was also requested.

• Clojure doesn’t seem to have any plan for Android integration, this is pretty sad considering how much computing power is employed there, and how big of a showcase mobile development is :(
• I think that the limitations of their respective host languages are holding Clojure and ClojureScript back.
• Is there a Clojure project that compiles to WebAssembly?
• So many people want a native Clojure. We need a native Clojure without JVM. Is there a plan about this?
• The advent of GraalVM, and the resulting ability to build Clojure executables that startup up quickly has been a game changer. The slow startup time and need to use a JVM has been a real impediment to Clojure’s adoption as a general purpose language. It would be even better if someone would pursue a Clojure native x86_64 compiler which would generate native executables, but that is probably not going to happen. Ensuring that Clojure can run well with GraalVM is probably the most we can hope for, and there is plenty of work to be done there.
• Difficulties in running on Android may end up forcing me to port all the existing desktop applications off of Clojure to pure Java/Kotlin solutions.
• Targeting two of the most popular VMs is great, but being able to get native performance is always a wish, like LLVM.

Typing

For the past few years people have been less and less worried about types. I suspect this is mostly due to spec.

• Love Clojure. But at two Java shops over four years, the lack of static typing (the ability to command-click identifiers in IntelliJ and navigate to their source, the ability to refactor) has prevented me from winning over colleagues. TBH it’s also reduced my own enthusiasm since the prospect of me working on our 1.6MM LoC project without static typing honestly scares me.
• I’ve selected “no static typing” but matching Haskell is not my intent. Lack of static guarantees is what bothers me. If it were possible to reject programs that are guaranteed to fail, that would be an improvement. For example: (clojure.string/replace nil #"a" "b") or (clojure.string/replace "abc" #"a").

ClojureScript

Shadow CLJS was mentioned by many people as having been a great part of their workflow. For those not using Shadow, externs remain challenging.

• shadow-cljs made me continue developing ClojureScript + started using it in backend services. It provides significantly better support for NPM libs than lein-cljsbuild that I’ve been using before.
• Without shadow-cljs we wouldn’t have been able to use clojurescript because we found it impossible to get the npm packages we needed to work.
• It’s not at a terrible state right now, but I’m at least slightly worried about more divergence between Clojure and ClojureScript in the future.
• shadow-cljs does great job on compiling clojurescript and npm integration, but it more and more diverges from the standard compiler. I would love to see shadow-cljs merged into the mainstream clojurescript compiler. In general: I would like to have better, easier way to compile clojurescript without setting tons of flags.
• Feel like cljs could make an amazing, even-better version of dash (maybe powered by Reagent/re-frame).
• Although work has been done on externs, I find venturing into JavaScript interop fraught with peril. I would be very happy if interop would just work, same as Java interop. Most frustrating is that development builds work but releases don’t. Catching these problems early would seriously mitigate the issue. For now I’m using cljs-oops library, which works very well, but it feels kind of a hack. Overall I’m very content with ClojureScript though!

Setup/tooling

Clojure’s tooling has continued to improve. This year lots of work has been done adding plugins or expanding functionality of the new official Clojure tools. clj on Windows was asked for by many people. Maintainer burnout seems like a significant risk to the Clojure tooling ecosystem.

• I’m happy to see that many have realised we need to find ways to better support the development of CIDER, a crucial part of Clojure development infrastructure. Seems like the lead dev has been burning out recently, and many of us depend on his (and a few others’) goodwill.
• It has been a challenging first year in obtaining high productivity with the tools. Would be great to see a simple but capable tool set get some focus, e.g. Atom or VSCode.
• I no longer want to work with CIDER or Cursive, rather, I’d like to work with REBL + a REPL as my IDE. I believe we can have a renaissance of Clojure tooling if prepl becomes demystified and/or we add a tap-repl, something like tap> to the Clojure repl. This would allow tooling to be added and removed dynamically.
• Please port clj to Windows!
• clj for windows please.
• We need clj under Windows. Is it possible to release it?

Compliments

As always, the vast number of comments were compliments to Clojure and the core team.

• Keep up the good work! 👍
• Clojure is beautiful, functional and concise. It really rejuvenated my love for programming.
• I absolutely love Clojure 💚
• I really appreciate the well thought out design of Clojure. We feel that Clojure gives us distinct advantages while providing a language with minimum disruption.
• 5 years later and I still enjoy writing Clojure. Thanks to all those who make it extremely productive and fun to use!
• I really appreciate all the work Cognitect and the community abroad put into making Clojure and the Clojure community a joy to work with. Keep up the good work!
• It’s my 11th year with Clojure. What a journey. Thanks, Rich and everybody.

Conclusion

Clojure is a great language, and people are very enthusiastic about it. Its adoption in business continues to grow. There are a number of areas for improvement still, especially if the Clojure community wants to grow further. Not all of this work needs to go through Core though, particularly in areas of documentation and guides, libraries, and tooling.

I worry about the Clojure community losing key contributors. There are a few linchpins holding a lot of things together; if we lose them, it will be hard to come back from. If you don’t want to see this happen then please support the libraries and tools you rely on by contributing code, documentation, issue triage, or money.