I doubled my salary using it and changed industries to much more stable industries
I've been to a lot of conferences and meet ups in my career but the feeling of joy and inclusivity at Heart of Clojure was unreal
The community is still alive and well, my favourite passionate sub culture in the Clojure community at the moment is the Jank community, building a Clojure Dialect for low level work an incredible amount of work but they're doing it anyway
The problem is businesses aren't really interested in stability integrity or joy when it comes to their languages they want to commodify their developers by forcing them to write the most popular and replaceable languages possible
Then they're surprised when the quality of developers they're able to hire drops and the quality of their software drops it's all just a race to the bottom - emboldening companies to try and replace developers with AI and destroy their own companies in the process
What surprised me the most in working with Clojure commercially is how many commercial developers did not get the ethos of the language or have watched the rich hickey talks or use the REPL, all they see is restrictions and unfamiliarity I don't know how these people got hired without a passion for the language - lots of them get promoted to run Clojure codebases
Yeah, this continues to stick out. The amount of people I've come across who do Clojure development and restart the application (really, the JVM process, kill it and launch it again, over and over!) is way too high, considering the first "real" reason I had for moving wholesale to Clojure was a shorter feedback loop. If that's not one of your goals when moving to Clojure, I'm not sure what you're up to really.
1. multimethods, if you change the dispatch fn you can't get it just with a recompile, there are tools to help with this but i'm not yet in the hang of using them after several years. (Many people don't hit this because they don't use multimethods. I love multimethods for the use cases I've hit so far with clojure.)
2. interceptors (pedestal) - I love this pattern and lib, and they've made moves toward improving repl friendliness, but I find I need to recompile two NSes typically to get a true reload even in dev mode (the one where my routes are defined and the one where a particular interceptor chain is defined). sometimes i lose track of what i've reloaded, and I dont know if a bug is "real" or just an artifact of forgetting to recompile - "f it, just restart the repl"
What I've seen people do, is restart the process after each change like you typically do in other languages, rather than evaluating the current form...
vars and functions too. It's the biggest issue: the inevitable mismatch after a while.
As soon as I've got any doubt there might be a stable cache or a mismatch, I'll just "nuke the current CIDER buffers and relaunch cider-jack-in-clj&cljs". And it takes 1.3 seconds.
I'll also regularly spawn, from a terminal next to my Emacs, all the unit tests related to what I'm working on, in its own JVM / process(es). I'm not talking about running tests on commit (which I can do too). I'm not talking about running tests when I modify a function.
I was there 3000 years ago when Java 1.1 was using green threads on Linux and using Java on Linux required a serious leap of faith (but I knew... I knew it'd take the world... And I knew great things like Clojure would then come).
Now a JVM starts and exits in 40 ms.
Emacs starts and exit, with 4 000 lines of elisp customization I created over the years, in 1.1s.
I cider-jack-in-clj&cljs spawning both a CLJ and a CLJS REPL in 1.3s.
Clojure devs definitely should modify vars and redefine functions at runtime and use the REPL etc.
But there's no need to let a REPL live for one week like GP is suggesting. I can launch my entire app, including Emacs and two REPLs, in 2.5s. While at the same time having all my unit tests being launched in another process.
At 2.5s to "restart the world", there's no reason not to do it more than once a week.
P.S: also stale caches are a thing in this world. It's sad but it's simply how it is. How it's always been. Restarting the whole world, while in dev, helps also deal with a great many stale caches issues that may not be related to Clojure but to other things (e.g. I didn't invent the "disable cache" button in browsers' developer tools and there's a reason it's there).
Also, thanks to the focus on stability and practical usage, I don't get my rug pulled out from under me every couple of years, like with so many other languages and environments. This is incredibly important and not immediately visible when "choosing a language to use", because the new shiny and the warm fuzzy are irresistible pulls. Clojure is not the new shiny and it's not the warm fuzzy, but it is your stable long-term companion for building complex software that is maintainable.
My first startup was all Clojure. AWS only had a dozen or two products and I think we must have been the first to compile Clojure to JS and run it on Lambda in production (the only runtime was Node.js 0.10 at the time).
Anyway, I cannot wait to watch this
studying them makes you smarter, which makes you better at using the practical stuff.
Sometimes I think I was happier before I learned Clojure.
I miss it just like I miss the program language and type theory group meetups in SF and working through problems in dependently types languages like Idris and being out of my depth.
Sometimes I think I was happier before I learned Clojure.
Ignorance was bliss.
Good to see David Nolen (aka "swanodette") is in the documentary too.
As a bonus here's a recent talk from David Nolen about Clojure/ClojureScript and using DOM morphing instead of React.
If you don't want to watch it all, just take two minutes to watch from 23m15s to 25m15s. He compares a behemoth slurping all the browser's CPU and RAM resources versus a 13 Kb of JavaScript + Web components and DOM morphing:
His talk is presented from Emacs, gotta love that too...
However, as someone that rather use Lispworks, Allegro, Racket, there is also Cursive on top of InteliJ.
However note that XEmacs was my IDE replacement during my first UNIX decade, due to lack of proper alternatives, so I do know about what Emacs and its derivatives are capable of, no need for yes but replies.
I maintain that Clojure is the best AI-first language due to the lightning-fast iteration via the nREPL and Clojure's token efficiency.
Things have been different for well over five years --- about a third of Clojure's life. There are so many first-class options now. When teaching Clojure, I direct everybody to either VSCode + Calva, or Intellij + Cursive.
LSP has really upped the game too. I rebuilt my Emacs development workflow around LSP for all the things.
These days, I sometimes forget to fire up the REPL, because of all this fantastic "static analysis style" developer tooling by borkdude and eric dallo.
Much gratitude to all the toolsmiths from all over the Clojure ecosystem. Special shout-out to LightTable for upping the game for everybody. I was very sad when the project went dormant.
In fact, I first presented Cursive at the conj 2014, and I'd been working on it in open beta for perhaps a year before that, so well over 10 years!
...all this fantastic "static analysis style" developer tooling by borkdude and eric dallo.
ahem
It’s also been a privilege to participate in the community. From Clojure west to the Conj, to the online discussions. Huge thanks to everyone that’s made this possible over the decades.
However there's no doubt that this is one of the primary reasons why Clojure became relevant and widely used (for a niche language). Seamless integration (or even improved integration) is very useful.
Another language that takes this approach is Zig. My intuition is that here as well, it's a unique selling point that will help with adoption and day to day usefulness.
I like maintaining the history in one place, nicely done.
I don't use Clojure much anymore, but two hours ago I updated two chapters in my old Clojure book because the examples had 'gone stale' and that was fun.
Also, in your view, is Clojure better suited for ML / AI apps? And if so, what is stopping it from being more widely adopted. I read the interop with Python ML libraries is good?
The best tools usually need a level of skill or patience that most developers just don't have time for. And companies have to ship with the developers they actually have, not ideal ones.
Lisp, formal methods, immutability, property-based testing - we agree on these. They just demand more than most people can give under a real deadline. A tool that shines in expert hands but falls flat for everyone else will lose to a tool that's just okay for everybody. Every time. That's basically what "worse is better" means.
In our industry we tend to approach things with "scientific methods", without actually using scientific methodology. Nobody experiments developing a real business solution with multiple teams using completely different set of tools just to see which one proves to have better ROI. What we do instead is that we go to forums and emotionally "mansplain" our anecdotal, subjective feelings about a tool or technique. Anecdotes aren't completely worthless; they're low-quality evidence, which is different. A senior engineer saying "every time I've seen a team adopt microservices before they had the operational maturity, it ended badly" is transmitting pattern-recognition from, say, fifteen projects. That's not a randomized controlled trial, but it's also not nothing. But there's flood of "unfalsifiable anecdotes" - claims structured so that any counterexample gets explained away ("you weren't doing real TDD...").
Rich Hickey's talks are not science - they're argument from principles, with illustrative examples. But they're honest about being that. He doesn't pretend to have benchmarks proving immutability is better; he reasons about it from costs and trade-offs and lets you decide. That's a legitimate mode of technical discourse. Contrast with someone claiming "studies show" functional programming reduces defects by 40%, citing one paper with n=12 undergraduates. The second is worse, and it's worse specifically because it's pretending to be scientific while the first isn't. I think the solution is not to make the field more rigorous and more scientific and require solid peer-reviewing of every idea. It's making the field more honest about the kind of claims we make.
Clojure remains hard sell to beginners because they haven't suffered enough yet. Experienced engineers get excited about immutable data because they've spent nights debugging race conditions. They appreciate simple functions-and-data because they've been lost in a tangled class hierarchy. The language solves problems they've actually had. Junior devs haven't hit those walls yet, so the solutions feel pointless. Why would you care about a painkiller if nothing hurts?
But then you have companies like NuBank, who chose Datatomic / Clojure and trains new devs in it.
So it's about tech leadership with a 'nobody got fired for choosing IBM' mindset not wanting to take risks. Go with the 'safe' option... Python, TS, etc and their respective ecosystems and developer pools.
Or is the reality that Clojure put you ahead back in the 2010s, but in 2026 it only offers marginal business value and benefits.
Anyway, I'm a newbie and am continuing to learn it because I want to learn to think differently about software architecture.
And also it has inspired a few other clojure datalog databases, so there is much more choice: * https://github.com/datalevin/datalevin * https://github.com/replikativ/datahike * https://github.com/threatgrid/asami
There is also xtdb, but it abandoned datalog and is going in another (albeit interesting direction) https://xtdb.com/
here is a comparison website, but it is somewhat out of date: https://clojurelog.github.io/
stability is boring to talk about but it's the thing that actually lets small teams survive long enough to win.
My downsides compared to Clojure: no destructuring in parameter declaration. No immutable by default.
But it turns out I prefer typed languages. Which isn’t a thing I’m going to argue about!
back in the day used to use clojure to write a fintech app but not sure if it is still relevant has uses vs other langs that have emerged
I've wrote about this in more detail here if you're interested https://yogthos.net/posts/2026-02-25-ai-at-scale.html
The industry should have optimized for hiring people interested in PLs like Clojure instead of LeetCode drillers. Clojure is rarely the first, second, or even third programming language people choose to learn. It demands a specific vision, dedication, and discipline that fundamentally transforms how people think about computation, data flow, distributed systems, and concurrency. The ROI from hiring an average developer experienced in Clojure has the potential to significantly exceed that of a typical hire. Even when there's zero Clojure in prod.
For me it's the opposite, the dense code is easier to review, because the proposed changes are almost always smaller and more informative. Contrast a change in a typical TypeScript project where changes propagate across tens of files, that you need to jump in-between just to understand the context. In the time it takes me to ramp up understanding what the change is, I've already completed the review of a change in a Clojure program.
I find it also easier to just grab the code and interactively play with it compared to do that with 40 pages of code.
but in my experience its amazing the overall quality of Clojure code in the wild tends to be higher than your typical language so AI's training on Clojure tends to be on modern and high quality code and the language is very token efficient, you can also tell AI to interact with the REPL to avoid restarts
The only downside I've seen reported is mis-matched parens but for me models have been strong enough to balance parens for about a year at least it's not something I actively work-around even though there are work-arounds like brepl and others
FWIW, I never get mis-matched parens when working with Claude Code in Clojure. I guess the key is to use clojure-mcp tools. If there ever is a mismatch during work (rarely, but I've seen it happen), claude fixes it using the tools right away.
Ask AI to build something. By default it will use python. Sometimes js or typescript.
Ask then to do the same thing in Clojure. The result is generally an order of magnitude better. Shorter, easier to read for both humans and llm. Easier to adapt to changes.
The repeated code on the steps is actually the more interesting tell to me. An artist would vary that deliberately for visual interest. A model just tiles what it learned looks like "code."
That said, the pencil sketch theory is compelling. Hybrid workflows where a human does the composition and an AI handles color/rendering are increasingly common, and they produce exactly this kind of uncanny result — strong underlying structure with strange surface artifacts.
Whether it is or isn't AI, the irony of a documentary about a language whose community deeply values craft and intentionality potentially using generated art for the thumbnail is at least worth a raised eyebrow. Not outrage-worthy, just... a little incongruous.
https://www.linkedin.com/posts/cult-repo_call-us-old-fashion...
