Why I ever wrote Clojure

I notice too that a noticeable number of people pick up Clojure because it's new and shiny. As a longtime Clojurian I find that attitude can be disappointing to run into, like when you realize a growing friendship will die because they're not serious about living in your city.

I don't claim to know the man but the reasons Rich wanted Clojure are quite concrete, well documented, and rational. Java programs of the time were a particularly heinous form of OOP; we should not be surprised that a clever programmer would grow a preference for a dynamic, functional-first style. He found lisp superior (in interactivity, expressiveness, yadda yadda) and wanted to use it professionally.

To work in lisp required delivering something indistinguishable from a JAR (or other mainstream proglang executable). He had the realization that without immutable data structures baked into the language he'd always be subject to Other People's State.

If you think about these points logically they lead pretty straightforwardly to creating a (pragmatically) functional, dynamic, hosted lisp.

Rich has written about the history and motivation behind Clojure here: https://dl.acm.org/doi/pdf/10.1145/3386321

I find solving business problems exciting. I didn’t really get into this business to purely write code or only work with novel technologies. I got into to empower others to do things they otherwise wouldn’t, couldn’t, or didn’t think to do.

To me, the language I work with is such a small slice of the pie. The problems don’t even have to be novel, I simply like approaching a problem and solving it well, and hearing the feedback about how it helps.

Fintech benefits from concurrency, immutability and all, so obviously there is much more nuance to "why fintech uses Clojure".

I need the money to get by, but at the same time, it’s hard to get enthusiastic about writing yet another RPC service or RESTful CRUD. This is partly why ketamine-fueled principal engineers often decide to rearchitect the universe, add Rust to the network layer where it makes no sense, or go ham with SWIG interfaces.

A few things that have worked for me: switching stacks. I started in data science, moved to Python/Node backends, and then switched to distributed systems and databases using Go. Switching teams and companies can help, though more often you just end up trading one bad culture for another.

This is a hard problem to solve, and boredom is real. But the solution isn’t bringing in some funky, untested stuff just for the lolz. Too many teams allow engineers to make the stack look like a mandrill’s face and then suffer the consequences.

But why speculate on Rich's motivations? He has spoken extensively on the subject. (Hint: It's not because he was bored.)

clojure's data structures for example enable simpler concurrent work on stupid enterprise data.

however.

I've seen favorite hot fancy XYZ bit rot in large enterprise code bases. the oh so bored original author long gone. boring architecture documentation missing. business critical underdocumented unmaintainable genius code. and I'll kneecap every greenhorn that tries to add such bored kid complexity in my vicinity.

get me right: rust and clojure and friends are great tools and you'll have my back if and where they are needed and add value. then we'll go all in. but no bored kid complexity. go and find yourselves some niche product companies, non enterprise, with hard tricky problems to solve and do genius programming there.

That aside, I got into Clojure because churn everywhere else is exhausting. It's pragmatic with interop, you can use with the new shiny thing without leaving your garden or losing your sanity.

EDIT: you must have forgotten how bad (mostly) it is everywhere else.

Well he spelled out the motivations in numerous early presentations so I don't think he'd take kindly to the implication they were BS.

I remember a funny quote along the lines of, he felt the concurrent software he'd already written in C++ and Java had required "He-Man" levels of perspiration to actually get correct.

Not sure if Clojure is that special here, it's probably the same with other appealing programming languages that have cultures distinct from default enterprise PL cultures.

I’d rather work on an interesting technical problem in Java than a boring one in Haskell.