Clojure’s Adoption
Ever since I took up Clojure as my preferred programming language in 2013 I’ve been asked or seen in the Clojure Community discussions around “Why is Clojure not widely adopted in the software development industry”?
If you want some perspective on the arguments in this debate here is a small selection of the discussions:
- Why is Clojure not popular?
- Why Clojure is not widely adopted like mainstream languages?
- Some thoughts about Clojure, its latent potential and adoption
I’ve engaged in some of these conversations over the years and I’ve put forward similar opinions as many of the respondents in the discussions above.
The Usual Suspects
The arguments over why Clojure is not more ‘popular’ range from the banal to the ridiculous:
- there is no framework ‘to rule them all’
- there is no ‘killer application’ to ‘rule them all’
- functional programming is hard
- Lisps are hard
- there are too many parenthesis
I’ve left off this list the most ridiculous argument because it’s less of an argument and more of a self-fulfilling prophecy “We can’t hire 100 Clojure developers”.
This last one is simultaneously re-enforcing a reason not to use Clojure by not providing demand for developers to learn or migrate to using Clojure but is also an example of misunderstanding Clojure’s benefits of being able to do more with less developers by assuming you even need 100 developers. Unless you’re Nubank sized you probably don’t!
However, although annoyingly silly this argument about a smaller pool of developer talent is probably the most destructive argument against increasing Clojure adoption as it’s one non-technical managers without a detailed understanding of the ‘economics’ of the constraints and benefits of different programming languages latch on to.
You can read in the many discussions online (some I mentioned above) the somewhat subjective analysis of the most common arguments, however in thinking about this recently I thought I’d attack the problem from the opposite angle.
Why do people adopt Clojure?
In order to get to the root of ‘Why’ people and organisations find Clojure interesting enough to adopt we need to look at who adopts Clojure.
Who adopts Clojure?
I will use a point of personal privilege by ‘speaking from authority’ by citing my personal experience of working with more than 7 organisations that decided to adopt Clojure, working on the programme committee of a Clojure conference for 4 years and spending over 7 years talking to Clojurians online.
My experience is that most people who were in the position to be decision-makers in adopting Clojure in an organisation are:
- as decision-makers they tend to be senior in terms of job title and have > 8 years of software development experience,
- they are exclusively technical and either still hands on with code or recently removed from coding,
- they have extensive experience of working in some quite complex problem spaces,
- they are not directly from academia although some have higher degrees their experience is grounded in solving real world problems,
- they have extensive experience of building software with the object-oriented paradigm (and sometimes also procedural paradigm) but not necessarily a functional programming background.
Obviously my experience is not a scientific survey but these characteristics seem to be prevalent in the decision-makers who adopt Clojure.
What organisations adopt Clojure
For this question we have some slightly more objective data. The State of Clojure 2022 survey:
As we can see the majority of organisations using Clojure are < 100 people in size.
Perhaps more telling is the number of people in the organisation using Clojure. It tends to be either organisations with small engineering functions or just a few teams in the organisation.
What’s Clojure being adopted for?
What kind of applications is Clojure being put to?
As we can see most people are currently using Clojure for web development, building and delivering commercial services and enterprise applications. We can fairly assume that the Open Source development is supporting the building of the rest of the applications.
Programmers adopting Clojure
What about the kinds of people using Clojure? What does that tell us?
We can also see that most people moving to Clojure come from a programming language typically used to solve practical business problems. These languages are also typically used in web and mobile-based applications rather than more scientific or engineering problems. These languages are also primarily object-oriented in focus although several can be written in a more functional programming style.
Judging from the number of people who skipped this question (17 of 2373 = 0.7%) we can assume that very few people are new to programming. Almost none it seems.
Lastly, how long have people adopting Clojure been programming professionally?
and how long have they used Clojure for?
We can see from this that most people using Clojure have been programming for more than 5 years and these two results seem to reinforce the assumption that almost all have come from programming in another language first. Also most people adopting Clojure seem to stick with it (although that’s hard to determine solely from the people who’ve stopped using it as this is only the respondents to the Clojure survey who would be self selecting to be mainly Clojure users, the high number of people using Clojure for > 5 years is indicative of high retention).
Characteristics of those adopting Clojure
So, what does this tell us about ‘Who is adopting Clojure’?
- they’re solving pragmatic business problems,
- they’ve come from other programming languages (mostly object-oriented focused),
- they’ve a lot of experience already before coming to Clojure
Why people adopt Clojure revisited
So, back to the earlier question, ‘Why do people adopt Clojure?’.
The answer I will give is obviously subjective to some extent but rooted in my personal experience in working with over 7 different organisations on over 35 different services or applications.
I believe that people adopt Clojure because they see in it’s philosophy and constraints a language that tends to naturally support:
- simple code (as Rich Hickey will tell you definitely not the same as easy!),
- code that’s easier to change,
- code that’s easier to reason about with regard to state changes,
- code that’s expressive of the problem to be solved (i.e. more code related to the business problem and less code related to just running the software)
So, why is Clojure not more widely adopted?
Again this is my subjective opinion, but I think the answer to that lies in the profile of who recognises the need to adopt the language. I think that you have to have suffered a number of failures and frustrations with other programming languages to recognise that the benefits far out weigh the alien syntax of a Lisp which has a functional programming paradigm and immutable data by default.
Photograph attributed to ~bostonbill~ under creative commons license.
Leave a comment