6 months of Clojure

Chris Bowdon
3 min readDec 15, 2018

--

I left `$SAFE_ENTERPRISE_ROLE` about six months ago to do Clojure development full time at a “scale-up” company (i.e. a bigger start-up). I’d long admired Clojure from a distance, but what’s it like up close?

Now seems a good time to record some thoughts on the language, community and everything.

Language itself

I’m convinced that Clojure is the best Lisp, because it is the only one where working with non-list data structures, e.g. hash-maps, isn’t painful – in fact it is a really pleasant experience. Coding with maps is efficient and reads well. (If you ever need to punish a naughty programmer, make them use hash-tables in Emacs Lisp.)

Like other highly functional languages, Clojure is very concise and this is a double-edged sword. The best Clojure code says in 5 lines what another language would say in 100. The worst Clojure code says in 5 lines what another language would say in 500. It is possible to write very dense code that occupies far more head space than lines in the page. This reminds me a lot of Haskell. But thankfully in the wild this kind of extreme concision is rare.

The only pain point I’ve felt is around tools.deps, the new way to manage dependencies. I’m keen on using it as I like the simplicity and separation of classpath and compilation concerns – it makes particular sense for a language with multiple hosts – but it’s only a year old and not as well supported as Leiningen, which “just works”.

Community

I have this suspicion that the average Clojure programmer is older compared to the average for other languages, particularly JavaScript. Perhaps this is just projection because I’m a bit older now than when I was a JavaScript enthusiast, but I get the feeling Clojure appeals to those who value simplicity and stability over exciting new features.

The evolution of the language is definitely along those lines. Breaking changes are rare; new features are always complementary. And I see it in the ecosystem, which doesn’t have that tiring JS-level churn of libraries and build tools and frameworks. Many popular libraries are not actively developed in Clojure. Not necessarily abandoned, often it just means the author has done all the features they want and is only responding to bugs.

Perhaps if I’m right about Clojurians being older it would explain this – older people typically have kids and less time for open source.

Myth busted

There is this myth that hiring is difficult for Clojure roles. Finding experienced Clojurians is difficult, true, but finding talented and experienced functional programmers who would like to learn Clojure is very easy. My team has been able to be very picky about candidates on this basis. New hires are rapidly productive. I think there’s an element of self-selection here too: of course people who are keen to learn Clojure are going to put in the effort to ramp up fast.

Something something simple easy

Most of all, I’ve come to really appreciate the lack of ceremony when writing Clojure code. There’s no complex types that need to be lined up – almost everything is a map or a vector. These might not be the ideal data type for every problem but they are pretty good types for most problems and working with them is a breeze. There’s a lot to be said for having a small number of well-designed datatypes and a fleet of functions to manipulate them.

So there we go, 6 months into my Clojure adventure and having a great time. It turns out hammocks are very comfortable.

--

--

Chris Bowdon

Acting CTO at Polecat. Past lives include: physicist, software engineer, data scientist.