Clojure is a "robust, practical and fast programming language" whose original design goals were aimed at giving developers "succinctness, flexibility and productivity". It turns out that most organizations today are interested in achieving those very goals - as the landscape evolves, they need technologies that help them move faster, respond more effectively, and to take advantage of new architectures and infrastructure. In short, they need simple tools that help them be more agile.
In this, the sixth consecutive year of the State of Clojure survey, we are seeing the evidence that Clojure is moving across the chasm from a niche tool used by explorers and hobbyists to becoming a critical part of the commercial development landscape, and that its adoption is spreading both broadly among companies, but also more deeply within them.
Before we get to the results, we'd like to first thank everyone who took the time to respond to the survey this year. Response was up more than 75% this year, with 2,445 total responses to analyze. This kind of data is invaluable to the people and organizations using (or considering) Clojure today. As always, we'd also like to thank Chas Emerick for starting the survey back in 2010.
Developers are often faced with enormous pressure to deliver business value in the face of many complicating factors: changing requirements, friction with or slowness of interacting with other teams, mixtures of legacy and modern infrastructure, rapidly evolving architectural designs, and many more. They are seeking tools that let them develop faster, deploy early, and reason about the underlying problem. Respondents value Clojure for those features that directly affect these needs; the top four answers to "How important have each of these aspects of Clojure, ClojureScript, or ClojureCLR been to you and your projects?" are functional programming and immutability (both aimed at making complex problems easier to reason about), and the REPL and ease of development (aimed at allowing developers to be more responsive to change).
"[Clojure] made programming fun again. I'm doing bigger projects that are much more complex in less time than I ever have before." - from comments section
Companies facing this push for more agile technologies have found a home in cloud infrastructure; in study after study, "agility" and "responsiveness" beat "cost" for why organizations pursue the cloud. This year, we asked our respondents what type of infrastructure they deployed to, and 1,735 reported either the public cloud (1,164) or private/hybrid (571), compared to 1,101 deploying to traditional infrastructure. The same factors that drive people to adopt cloud infrastructure are the same principles behind Clojure, so it is no surprise to see the overlap in adoption trends.
All this agility and simplicity isn't very useful unless you are taking advantage of it to solve real problems that create value. When asked "In which domains are you applying Clojure, ClojureScript or ClojureCLR?", five of the top six answers were Web Development, Math/Data Analysis, "Big Data", Commercial Services and Enterprise Applications. (Open Source was the overall #2 response, and it is difficult at this granularity to assess the nature of those projects.). Based on this data, Clojure has found a home in critical business domains.
"Adoption of the Clojure language within my Company was aligned with a move to more agile practises and has been a huge success so far, delivering that rarity within a government aligned organisation; a project that was on on time, successful both internally and with customers, and was an enjoyable experience for the developers!"
Now that we know some of the "why" and "how", let's look at little at the "where." Any new technology has an adoption curve that starts with explorers and pioneers, then moves on to settlers, and finally to town planners. The explorers and pioneers survey the landscape, strike out in new directions, learn and report back. When the settlers move in, that's when growth starts to happen. When asked to "characterize their use of Clojure, ClojureScript or ClojureCLR," an outright majority of respondents said "I use it at work." The settlers have clearly moved in. Based on the comments, we see further evidence that many teams that have adopted Clojure at work are looking forward to growing those teams in the coming years.
"This is my fourth year hacking Clojure at work. We've grown from 3 to 30+ devs writing Clojure. It's been a pleasure, look forward to seeing that number get bigger next year :)"
"We're moving most of our code from Ruby to Clojure and currently implementing a NLP/big data stack in Clojure. So far it's been a blast."
Where companies are adopting Clojure, they are also not being shy about how they use it. When asked to describe what types of applications they are building, 1,007 responded "corporate or enterprise wide"; more than 42% of total respondents indicated that their company was making a critical investment in Clojure. 1,643 respondents also said they were using it for "Personal" projects, showing the expected leading edge of explorers bringing a new technology into their organization in their own discretionary projects.
When we look at just those respondents who say they are using Clojure at work, a different picture emerges: 67% of those respondents say they are using Clojure for Company-wide/Enterprise applications, by far the most responses in that group.
As this trend of companies adopting or considering Clojure for their critical projects continues, another trend should follow along behind. When asked "What has been most frustrating or has prevented you from using Clojure more than you do now?," "Hiring and Staffing" is the second most common answer (right after "Error Messages"). Fully 34% of all respondents, 36% of those saying they "use it at work," list this as a blocker to further adoption. The more companies consider deploying Clojure against critical projects, the more likely they are to think carefully about how to build and grow a staff that knows the technology.
"The primary issue for adopting Clojure is finding developers. I am the Director of Engineering."
Staffing concerns are a double-edged sword; on the one hand, lack of a ready workforce can hold back adoption, but on the other, open positions encourage growth of that same ready workforce. While survey response is not a direct indicator of overall participation in the Clojure community, it is encouraging nonetheless to see the pool of responses grow by 75%, with 2,445 total responses this cycle. More importantly, we continue to see strong responses in "Just getting started" to "2 years" range on "How long have you been using Clojure, ClojureScript or ClojureCLR?" This correlates with our observation that roughly 60-65% of attendees at each of the last two years' Clojure/conj, Clojure/west and EuroClojure shows were attending their first Clojure conference. New people are learning and adopting the language, perhaps fueled in part by the growing commercial demand for that knowledge.
"Our experience adopting clj(s) in a commercial environment has taken a lot of effort in training, but it is really starting to pay off in spades. Om next, Datomic, and the availability of great FP libraries gives us a lot of leverage."
As Clojure itself has matured, so too has ClojureScript, and this year's survey demonstrates how much it has rounded out the development story. Fully 62% of all respondents to the survey indicated they were using ClojureScript; that number actually climbs to almost 66% of those using it at work. When you look at this cohort (people using ClojureScript at work), "Hiring and Staffing" continues to hold a high spot on the concerns list.
While ClojureScript maintains close ties to Clojure itself, the survey demonstrates that ClojureScript is being adopted as an independent front-end tool as well. While the grand majority of respondents indicate that they are using ClojureScript to target a Clojure server-side implementation (89%), there are a significant number of people fronting other server-side technologies with CLJS. We only asked about Node.js, Java, Ruby, Python, PHP and Erlang:
However, the free response comments for this question show a lot of people targeting Go, Haskell, Scala and C# as well. This indicates that ClojureScript is being independently adopted in some scenarios, and added into polyglot development teams.
ClojureScript extends the range of direct deployment targets for developers as well; instead of living only where the JVM lives, they can target JavaScript environments, too. While Browsers are by far the dominant target, people using ClojureScript for commercial purposes are spreading out to other targets, with Node.js, iOS and Android all coming in at more than 10% of the responses.
We think that having a broader range of deployment targets, and allowing developers to use the same language across those targets, broadens the appeal and makes it easier for teams to adopt the language(s).
"Clojure is great, ClojureScript is great and I'm very pleased that such a coherent full stack of tools exists to build stuff as an alternative to more mainstream techs."
In addition to pulling out some of the big themes we see in the Clojure community based on the "2015 State of Clojure" survey, this post provides a lower-level analysis of the specific questions in the survey, comparing to previous years.
First, it's important to note that the number of respondents this year (2445) was much higher than the last few years (1200-1300). This is a clear sign of the growth we've seen in the Clojure and ClojureScript community recently.
Similar to previous years, we see that almost all respondents are using the JVM-based Clojure and a significant percentage also use ClojureScript. The percentage using ClojureScript has risen over the past 3 years from 49% to 55% to 62% this year.
We continue to see a very strong commercial user base this year - a large number of people and companies are relying on Clojure as a critical part of their business. This is also the first time the largest group of people are using it work rather than for serious hobby projects.
This question was added this year to track where developers new to Clojure are coming from. Some key points:
This question existed in the first few years of the survey (as a single-select question with slightly different wording) and had mostly similar results (which was why it was dropped in 2013). We brought it back this year to get an update and see if things had changed.
Interestingly, JavaScript was effectively non-existent (1-3%) in these early years prior to ClojureScript, but is now one of the biggest contributors for new Clojure developers.
And of course, there were languages we forgot to list. Some of the most common in the "other" section were Perl and Objective-C / Swift (the numbers were smaller than any of the listed languages). It was also fun to see some people listing Clojure as their first language!
Clojure is used in a wide variety of domains for almost every conceivable kind of application. It should not be surprising that what we see in the question largely reflects the industry at large, which is dominated by web-based applications, open source, etc:
Some key points:
This is a new question this year, trying to get a handle on where Clojure is being used. However, the results primarily reveal that people are using them for both.
This is another new question this year, trying to get an idea of how Clojure is being used in larger companies, whether it's isolated to a single department or team or exposed across the enterprise and it was good to see strong support across in larger contexts.
This is a new question trying to gauge the impact of the cloud and deployment strategies for typical Clojure applications. Likely this reflects practices across the industry as a whole.
This is a new question to being tracking more information about how Clojure is used in the industry and establish a baseline for future years.
The results for this question are not too much different than what we've seen in the past - as a growing language we always see a large number of new developers.
These results are not significantly different than previous years - most users find the important features of Clojure to be functional programming, immutability, the REPL, and ease of development.
One place where some interesting differences emerge is when you examine how these results vary based on the primary language background from question #3. For example, Ruby developers find concurrency to be significantly more important than users from other language backgrounds. C++ users find concurrency, reducers (another concurrency feature), and protocols, records, types to be more important.
We are blessed to have so many good Clojure tools in friendly competition (to our benefit) and we've seen a variety of tools rise and fall in popularity over Clojure's lifetime. This year's breakdown looks as follows:
Emacs with CIDER continues to be the most popular development environment and the CIDER team continues to add important features with every release. There have been too many new things added in the past year to mention them all, but certainly the debugger support has to be one of the favorite new features.
The Cursive plugin for IntelliJ recently hit 1.0 and has enjoyed a surge in popularity this year creating a rich IDE experience, particularly friendly to Java developers accustomed to using a graphical IDE.
Vim and vim-fireplace were largely stable this year although the vim-friendly support in Spacemacs (which perhaps should have been mentioned explicitly in the choices) has started to slowly pull Vim fans over to the Emacs world.
Light Table surged in last year's poll, but dropped considerably this year. After it was open sourced it took a while for the Light Table community to gather itself, but there was a new release around the time of the survey that will likely boost its use again. The Light Table instarepl which shows inline results continues to be a killer feature for new Clojure users.
There was also an interesting story in the comments section for this question - we did not list web editors like Atom or VS Code in the choices and they were mentioned frequently. It seems likely that with the influx of JavaScript to ClojureScript developers that web-friendly dev environments like Atom will increase in use in the coming year. We also saw editors like Nightcode and Textmate show up in the comments as well.
We can see that over 90% of Clojure users are using Clojure 1.7, the stable release that came out last summer. It's likely that the two main features of the release (transducers and reader conditional/cljc files) are the reason for the rapid uptake. In particular, reader conditionals and cljc files allow developers using both Clojure and ClojureScript to maintain a single unified code base, an increasingly important and common use case.
Additionally, we see that 13% of users are already using the 1.8 pre-release versions (Clojure 1.8 was released on Jan 19th). This is a testament to the stability of Clojure across versions and the ability to upgrade with few changes to existing code.
We see that most Clojure users (87%) are using Java 1.8, the latest stable version, and only 31% continue to use Java 1.7 (which is now end of life). Perhaps most importantly for Clojure, only 4% of users continue to use Java 1.6, the minimum version of Java that Clojure supports. We will continue supporting JDK 1.6 in Clojure 1.8 but eventually we will drop that support.
We see almost no usage of the early access versions of Java 1.9 - it's likely that will change over the coming year.
Unsurprisingly, Leiningen continues to be ubiquitous with 97% use. The newcomer Boot has seen increasing use since it's release last year, now at 13%.
The intent of this question is to judge how people feel about libraries in the Clojure ecosystem as a whole.
It seems that most people feel that Clojure libraries are easy to find, their maintainers are receptive to feedback, and they are implemented well. There seems to be the greatest disagreement regarding whether libraries are accurately and adequately documented and how they compare to similar libraries in other languages. These results are nearly identical to the results of the last few years.
"Error messages" is the obvious choice that sticks out here. This was also the first time this choice was included in the survey so we don't have any historical data for comparison. We expect to evaluate possible changes in this area in upcoming Clojure releases.
In this year's survey, "Hiring and staffing concerns" was the next most common choice for the first time, likely spurred by the increasing use of Clojure at more and bigger organizations and the need for more Clojure developers.
The third most common response is about difficulties using Clojure for scripting - one common complaint here is startup time. Doing finer-grained analyses of the data revealed that users coming from Ruby and Python are most concerned about this, presumably as they are used to using those languages for scripting.
"Docs" was at one point the highest concern and continues to be important. A brand new web site was released on Jan 14th with open source content and we now have a place to start building better community documentation together.
"Static typing" was added to the survey in 2013 and continues to attract a rising number of votes (and comments). However, our suspicion is that rather than general static typing, the primary need that people actually have is documenting and validating domain data structures. This use can be seen in the success of the Prismatic Schema library.
In many ways, this reflects what we saw in the areas of frustration in the prior question.
Unsurprisingly, most ClojureScript users pair with Clojure on the backend to get the maximum benefits from a full-stack single-language solution. In some cases, developers are using Node on the server instead. However, noticeable numbers of people use alternate backends in Java, Ruby, or Python. There were a broad variety of solutions in the "other" comments as well - Go, Scala, C#, Elixir, Groovy, Haskell, Perl, R, F#, CommonLisp, OCaml, C, VB, and C++ were all mentioned.
The responses to this answer are not surprising, other than the interest in AWS Lambda (which can be used either from Clojure or ClojureScript).
The big story here is the strong showing by Figwheel, which was not well-known a year ago but is now one of the most commonly used ClojureScript tools.
The ClojureScript tooling space is changing rapidly as these results demonstrate - Figwheel makes a giant showing as a new tool here. It's nice to also see that the percentage using no REPL at all has gone down significantly (it was the leading choice two years ago).
To better understand how significant Figwheel has been, this is a comparison to last year:
ClojureScript has strongly embraced React since the early days, so the strong "Yes" result is probably not surprising to anyone in the ClojureScript world. However, it is a big difference from the greater JavaScript community where React is a much smaller piece of the pie.
There are no surprises here, as the answers are very similar to the last few years.
ClojureScript significantly changed the REPL integration story this year and tools are starting to catch up - this area should continue to improve this year. Two of the areas where percentages went down were in Editors/IDEs and in Portability. The former is likely due to some of the new tools like Figwheel and the latter saw a big change this year with cljc files and reader conditionals, easing some of the pain of creating portable code bases.
One area that is rising rapidly is Staffing - as ClojureScript matures it's being used more and more for real projects.
There were almost 600 comments in the open comments section at the end. Most of the comments echoed areas seen and addressed in the questions above, while another set were about very specific questions or complaints. Rather than summarize, we encourage you to read those yourself.
By far the most common sentiment (about half the responses) expressed general happiness or gratitude towards Clojure and the community. Some we particularly liked:
If you'd like to dig into the results more deeply, you can find the complete results here:
If you'd like to compare to prior years, see:
And also make sure to check out:
If you'd like a downloadable version of this report, please go here.