I have been writing Clojure since 2017. Unlike every other language that helps you achieve a task, Clojure helped me think.
Clojure for me is a rich vocabulary to talk interact with data. When Jank becomes stable, Clojure will be unstoppable.
I don't have much love for Java - it's an OK statically typed language - but I have the utmost respect for the Java runtime environment.
Clojure is a beautiful Lisp, and coupled with the JVM it's extremely powerful.
Every time I write another DTO → domain → DB mapping layer in Kotlin/TypeScript, I think about Clojure. I’m pretty grateful I learned it. It really changed how I think about software. Still, it’s a trade: less ceremony, more responsibility.
My favourite companion to Java, when on the JVM, especially because the host language community culture.
If you want a Lisp Machines like experience with Clojure, support the Cursive folks.
Clojure is the language that made me "understand Lisp", as originally stated by Eric Raymond and citet by Paul Graham: https://paulgraham.com/avg.html
It seems like a small thing, but Clojure's choice to open up for other types of parentheses made seeing the structure of lisp programs much easier. This helped me understand how code is data and how macros are functions that can transform both code and data.
An important design philosophy (which is also hinted at in the trailer) is "simplicity". Clojure is designed to give you the tools to build simple solutions to the problems that you want to solve. It approaches mutability, which is one of the key sources of complexity in programming, with immutable data structures. It's a really clever way to do functional programming where your data is copied a lot but the copies are lightweight.
I don't write Clojure any more these days. I'm mostly doing Rust. But it is true what Eric Raymond said: Lisp has made me a better programmer.
Also: XKCD 224 and 297
I am so glad that this has been made! And happy that it features so many familiar faces from the last two decades of Clojure. There is a lot more to a programming language than just the code committed.
I'm forever grateful for putting me onto this amazing language and even more amazing community. I know many others that feel the same way.
the wonders of visibility algorithm: https://news.ycombinator.com/item?id=47556827
Very cool. My first instinct was to buy a Clojure book.. so for those that had the same,
Programming Clojure, Fourth Edition 4th Edition is on pre-order scheduled to be released May 2026.
https://pragprog.com/titles/shcloj4/programming-clojure-four...
Clojure is IMO indisputably a good language within a certain scope, and especially relative to many other languages used in practice. However, I think it's greatest merit is not so much the language itself - and there is nothing especially innovative about any of its features per se - but that it introduced so many programmers to a more functional style and the selection of very practical features it includes (Java interop was a smart move, as the ecosystem is a major hurdle for adoption). Much of the fandom and enthusiasm IMO comes from the contrast between the other sorts of languages people use in industry - which traditionally are imperative - and this functional style. It is much easier to reason about functional programs than imperative programs where names can refer to one thing at one moment, and to another at another moment. Mutability really is bad and should generally only be used judiciously and in very confined and controlled contexts.
In my experience, while I have found Clojure enjoyable and practical, it is still a "dynamic" language. A good deal of run-of-the-mill programming can manage quite well with such a language, but as projects become larger, deeper, and more complex, the lack of static types really does become a cost and an impediment. To understand any function and what it expects, you often need to read a few layers in to find what exactly something consumes and returns. Types really are a boon in such code bases. Some may point to various schema libraries in Clojure. While these can be helpful, they are often comparably inscrutable in practice (both in terms of specification and the resulting errors) and really do not compare to bona fide types, especially with LSP integration. And when you model something using types, the code sort of just falls out of the type definition.
> `a -> a`; `[a] -> [a]`; It means nothing! It tells you nothing!
— Rich Hickey, Effective Programs[0]
[0]: https://www.youtube.com/watch?v=2V1FtfBDsLU&t=4020s
---
A disastrously poor take. I used to work at a Clojure company, and there's no chance I'd ever go back to that.
I've been running my business for 10 years now, relying on Clojure and ClojureScript. It is amazing to be able to base one's livelihood on a foundation that is so stable and well designed. Clojure has been designed by a very smart and very experienced person, and it shows. It has then been maintained and extended by a team built around a culture of maturity and stability, and the result is something you can rely on.
The fact that I can use the same language to develop business model code that runs on both the client and the server, or that I don't have to use a different on-the-wire format for sending data between them (EDN does the job great) is just icing on the cake in this context.
I am very thankful to Rich and the entire Clojure (and ClojureScript) teams for giving me access to all their work (for free!).
BTW, if you haven't seen any of Rich's talks, go see them — they are worth it even if you do not intend to use Clojure.