Looking back Clojure has been the best thing to happen to me in this industry
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
> 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
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.
I'm probably not the sort of person you're referring to, but I do regularly restart the REPL because
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"
Sure, so once a week or so you need to restart the process if you end up like that.
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...
The thing that happens to me is that I'll get something working in the REPL, then try to deploy it and it breaks—because unbeknownst to me, I had gotten my REPL into some state where everything was working, but a cold start doesn't look the same.
Is this a skill issue? Absolutely. Do I still restart the REPL frequently (not after every def, but often) just to make sure I'm working with the same environment my program will be experiencing at run time? Yes I absolutely do.
Ah yeah, been there, and probably the first time was when renaming a function but missing to update callers, so callers keep calling the old function, and you have no idea why the changes you made in the new function aren't working.
I have a this little function for clearing the current namespace that I call every time I rename any var inside a namespace:
Full test suites I run before committing essentially, in a separate tab altogether, then the full suite is typically also run in CI before any deploys.
> Yes, but without a clean REPL you can't easily be sure that your var definitions are what you think they are.
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).
Been over a decade since I used Clojure in anger, but at the time it really seemed like IDEs made it hard to use a REPL with a large codebase -- they seemed more to want it to be like a javac/maven stack. I assume that got better?
I am so thankful for Clojure. It enabled me to run a solo-founder business for the last 10 years in a sustainable and maintainable way. It allows me to manage a large complex codebase (client+server) because of low incidental complexity and the fact that the server and the client share most of the business logic code.
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.
In a previous life, I wrote Clojure every day and still look back fondly attending Clojure/Conj and sitting next to Rich Hickey and other Clojure greats at dinner.
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).
I’m no longer in a professional engineering position and have a family and toddler so less time for learning about or playing with program languages. Clojure is what really made me first start thinking about programming languages and down the rabbit hole of scala and Haskell and idris and type theory books. Which are incredible and I can’t recommend more and also not remotely practical.
I love the clojure, but I think a big downside is not being able to use it at work and now work feels like I'm being forced to work with stone age tools in comparison.
Sometimes I think I was happier before I learned Clojure.
I never understood this sentiment. Even if nobody on my team uses Emacs or Vim, or Clojure, Rust, Zig or Nix, or some browser extensions, or any other tool, nobody could ever directly deny me access or restrict the use of any of that on my machine, some vm-box or EC2. And once I prove their usability to me personally, I show that to my colleagues and typically people when impressed they start using them. Once you have more than three people, you can start discussing rolling it out for general use. Just this past year alone, I have convinced my teammates to use a bunch of tools they'd never heard of before.
It's more depressing if you work in a big organization where decisions come down from on-high instead of letting teams decide what's best. (Especially if one of those decisions is so-called Agile practices which were about empowering teams against on-high global decisions from management, but that's a digression.)
But yes, treat it as a job, and make time for "fun time" after work at home using your favorite tools and languages and OSes, and you can still be happy, especially because the bills are being paid. And even in restrictive corporations there still may be opportunities to introduce a little of your favorite thing... Clojure itself "snuck in" at a lot of places because it was just another jar, and it's not too hard to shim in a bit of Java code that then turns things over to the Clojure system. You can also try getting away with internal-only tooling.
If I had stayed at my last job a little longer I would have tried putting more effort into sneaking Common Lisp in. I had a few slackbot tools I wrote in Lisp running on my machine that I turned over (with pre-built binaries) to someone else when I left (but I doubt they're running still). The main application was Java, and there was already mandates from security people and others not to use other JVM languages.. at least in application code. I was thinking (and got a prototype working) of sneaking in Lisp via ABCL, but only for selenium web driver tests. It was a neat trick to show some coworkers a difference in workflow: write or edit a web driver test, one of your asserts fails or an action click on some ID that's not there fails, in Java you get an exception and it's over, you'll have to restart the whole thing, which for us was expensive because these test suites typically spun up huge sets of state before starting. But with Lisp, exceptions don't automatically go back up the stack, but pause at the spot they occurred: from there you can do anything in the debugging REPL that you can do normally, redefine functions, classes, whatever, and then resume the computation from where it left off (or at some higher part of the call tree stack if you prefer), thus no expensive restart.
There's also ways to introduce things you like that aren't just different languages. My team started doing "lunch and learns" at most once a week (sometimes less often); if anyone wanted to talk about whatever for 30-60+ mins during a lunch period we'd get together and do it. Sometimes that would be about specific work things being built, sometimes it would be about external stuff, ideas (e.g. the Mikado Method) or tools. Once I did a brief presentation about property testing and later on got the quicktheories library for Java into the codebase and handling some tests, and ended up not being the only one to occasionally make use of it.
I miss it. I’m now more removed and building software as a means to an end.
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.
I felt exactly the same, but recently started building side projects again in Haskell and fell in love again. Really brought my passion for software development back. 2026 feels perfect for that, as AI can help with things where one was stuck, not the stuck in a good learning way, forever in the past. Now is the time!
I love the clojure, but I think a big downside is not being able to use it at work and now work feels like I'm being forced to work with stone age tools in comparison. That gets quite depressing sometimes.
Sometimes I think I was happier before I learned Clojure.
Incredible: I had not idea NuBank discovered Datomic first and that it's Datomic that led them to Clojure, 100 million+ customers, and eventually acquiring Cognitect.
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:
Emacs has always had a tight link with Lisp communities, due to its history, including ties to Lisp Machines, so naturally many use it.
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 don't know if it's still the case, but at old clojure conferences, or meetups, or places of employment, emacs was a prereq and assumed (and the most enjoyable)
I think it was more like Emacs got Clojure development niceties early, particularly tight REPL integration.
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.
Thank you Colin for the outstanding work and selfless, continuous gifting and self-generosity. Cursive remains one of the important pillars of Clojure journey for many beginners and seasoned pros.
You just can't ignore the amazing collaboration and camaraderie between Clojure tools builders. - you Colin, Peter (Calva), Eric (clojure-lsp), Michiel (babashka, kondo, etc.), Bozhidar (CIDER, clojure-mode), Juan (flowstorm), Chris (Portal), and many others.
Everyone, instead of competing with one another just wants for people to find their best way of using Clojure, and that is really awesome. You can see the ideas freely circulating between spaces and creating great of awesomeness for everyone in the community. I'm telling you all this as someone who doesn't even use Cursive. I still can see your work. I can tell how valuable, important and vital you are for me personally and for many of my friends and colleagues. I salute you, and every other tool-making hero. Thank you, guys!
I’ve been using Clojure since 2013, and can say that it has been an enormous positive force in my life. I’ve been a very unorthodox user, most of my artworks were built using Clojure in some way. But I’ve also worked in industry, and there I think Clojure helped me avoid burnout on more than one occasion. Especially when running a startup built half on it :)
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.
Thank you! I’ve managed to shoehorn Clojure into everything from 3D model generation to VR networking servers for installations :D It makes so many things easier to reason about!
I wish I had a chance to open source. So much of it was done in mad hacking sessions to glue things that were never supposed to work together. Or contain all the secret sauce for one work or another. Maybe the next one!
Clojure is my favourite alternative language on the JVM, besides offering what Lisps have provided for decades, their philosophy of embracing the host platform, instead of all the talk that the next JVM will be rewriten in it like some others do, makes being around Clojure folks much more appealing.
When I was younger this actually irked me a bit. I wasn't familiar with either, so it felt burdensome to me. The tooling also wasn't as good as it is now.
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.
Clojure is a great language and ecosystem. I donated a little money to Rich's efforts in the early days (I loved his older Common Lisp - Java bridge so his Clojure project was immediately interesting) and I have been paid for a few years of Clojure development.
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.
What made you stop using Clojure or not so much anymore? No jobs in Clojure?
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?
I used tools that I was paid to use. After being deep in neural networks in the 1980s, ten years ago I dropped back into deep learning, thus mostly used Python.
> what is stopping it from being more widely adopted.
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?
Thanks for sharing your thoughts. Haven't seen it from that perspective yet.
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.
> Or is the reality that Clojure put you ahead back in the 2010s, but in 2026 it only offers marginal business value and benefits.
How so? Yes, some ideas from early Clojure have leaked into the mainstream, yet "absorbed some FP-flavored features" is not the same as "delivers Clojure's value proposition". Let's examine the proposition: "a language where I can iterate on domain logic at REPL speed with immutable data and good concurrency on a mature runtime", what does fit this description today?
- Elixir is the closest thing. Immutable by default, pattern matching, excellent concurrency, What we'd lose? Homoiconicity and macros of the same level, the host-interop story, data-orientation as a philosophy.
- F#. Immutable by default, discriminated unions, computation expressions, nice REPL, hosted on a mature runtime with full ecosystem access. Statically typed, which is a different tradeoff. What you lose: dynamism, macros, the Lisp sensibility, cljs-style multi-host story.
- Elm/Purescript in the frontend niche. Immutable, functional, good at what they do. Neither is a Clojure replacement because neither is a general-purpose platform play. Elm is effectively frozen. Purescript is healthy but tiny.
- Gleam on BEAM. Typed, functional, growing fast. Too young to be a replacement today, worth watching.
- Scala. I'd argue it shouldn't even be in the category despite the surface similarity. It's a different philosophy (types-first, expression-oriented, complex type system) and the REPL experience is not comparable. It competes with Clojure for "the non-Java JVM job" but not on value proposition.
- Kotlin. Even further from the category. Pragmatic Java-plus. Wins jobs Clojure might have won in 2015 but for reasons of "looks like Java, hires like Java" rather than matching Clojure's model.
- Before you say what seems to be everyone wants to scream about - Rust/Zig and Clojure solve almost disjoint problems, which is the first thing to say out loud when someone uses one to dismiss the other. I can dive into the details, if you insist, but I think this isn't the category for it.
The real answer to "is there a replacement": no single language hits all of (hosted + dynamic + homoiconic + persistent data + REPL-driven + multi-host via .cljc). Elixir hits most of the development-model points but throws out the multi-platform story and the Lisp. F# hits the runtime maturity and immutability but throws out dynamism. Everything else is further. What you actually see is Clojure holding a small, stable, well-compensated niche. And it's holding it like a champ - it offers real, practical, sensible benefits where every other stack have no similar alternatives for.
But the bigger point is that doing this kind of shallow comparisons is vain, because you really need to understand every language holistically - every language has strong points and weaknesses that manifest in certain scenarios, for certain domains, teams, different constraints. Clojure remarkably fits well more often than it doesn't. More importantly, the model and the ideas that the language promotes fit elegantly, even when you're not writing Clojure.
I would add one thing to the programming languages conversation: which languages make developers happy to use them? Personally, I have no emotional involvement with Python (sometimes the practical choice, but no excitement). I love using Lisp languages, and enjoy Haskell even though I am not a particularly good Haskell programmer.
See Mark's comment above. ML expert, wrote a book about ML for Clojure, but it seems he had to stick to Python, since that's where the ML jobs are. I've read a few times now that Clojure folks think it's much better suited for ML projects and yet Python has 'won' in the marketplace.
I'm just trying to understand why Closure hasn't caught on. It's marketed as a general purpose language, has all these amazing benefits, amazing community but now it's niche and adoption seems to be slowing and that's a shame.
So hopefully this documentary will help to increase adoption. Because I think we can agree it would be nice to see more Clojure jobs.
But what else can be done? Does it need better marketing? Better on-boarding for beginners?
Or is it futile because most newcomers and tech leads won't want to invest the effort to get over the initial bump of a steeper learning curve and see smaller ecosystem as a downside?
Yes, sad there's no European presence (unless I missed someone). There's tons of Clojure over there. Metosin, Juxt, Borkent, Gaiwan (Arne), Flexiana, Peter Strömberg (Calva), Dustin Getz (hyperfiddle/electric), Christophe Grand (ClojureDart), Bojidar (CIDER), Renzo, and many, many more.
They could've cut Zoom interviews in there - they are not expensive. The documentary creates a skewed image of Clojure being mainly in Americas, while in fact the big chunk of it is on the other side, where they have more conferences, (probably) more startups and (perhaps) people using it.
the "stable long-term companion" framing from jwr's comment is the part that sticks with me. every company I've worked with that chased the new shiny ended up spending more time on migrations than on the actual product.
stability is boring to talk about but it's the thing that actually lets small teams survive long enough to win.
I've always enjoyed using Clojure. Unfortunately, most of the things I do require interacting with the C world, so it has never been a real option as my primary language.
I also interact a ton with C and C++, but it's easy today to have Claude write a Project Panama wrapper and then put a nice Clojure veneer on top of the Java.
Less ex-user, more like: never really managed to get to use it at work I guess (just like it is for me). It is still a niche language (compared to the big ones) after all.
It’s a real statistical outlier, nearly every language people have moved on from gets negative reviews. Me, it was fun but it wasn’t for me and eventually I concluded a number of the fundamental design decisions were wrong.
Here’s one: Mike Rettig wrote a great post about this in the early days, long since lost to time. Didn’t take that much note of it at the time but grew increasingly convinced over time: shared memory primitives are a bad idea. We would have been better off with an architecture that prioritised message passing. (Not that you can’t do message passing in Clojure, just that it isn’t privileged the way STM is.)
These days, it’s mostly C#. It’s got one of the most sophisticated list processing modules of any language I know of, you can fairly easily write heavily immutable code. It’s a bit niche because Microsoft but it’s nonetheless solid.
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!
Clojure is more relevant than ever in post agentic coding because of immutability and the REPL. The two big problems with agentic coding is context growing in unbounded fashion, and agents being able to get quick feedback on what they're doing. Mainstream languages fail on both accounts. I've found Clojure has been a great fit for keeping agents on track.
It definitely is more "mainstream" than others but I just don't see the same level of attention and enthusiasm around it anymore. I'm sure it is still being used in many places but like Elixir, hiring remains on the tough end.
Hiring good talent was always problematic. This has nothing to do with the quality, capacity, and robustness of the language or its relevance. Hiring people who would love to use Clojure but have no prior experience is not that difficult - it's just that every company wants an expert, but they don't want to offer expert salaries. In places where they do, the competition is nuts, on top of that, experienced Clojuristas typically get interviewed and scrutinized with the same level of rigor as architects.
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.
I've had Clojure on my resume for 10 years, mainly to see if anyone would ask about it. Nobody ever has, until an interview a couple days ago. We'll see if it actually helps in leading to an offer, I guess.
I have the opposite experience - been using Clojure for over a decade and it feels like only that mattered for the last five jobs. Even though it's really only just one of many layers that required to do the job. I honestly would love to find a non-clj team and convince them to use it. There are so many useful scripts we write in babaska alone, it just sounds wasteful not to use that path, fully knowing of its existence.
Imagine what you'd use random shell scripts, Makefile/Justfile or whatever "scripts" the language offers, if any, but written in Clojure instead, run with Babashka.
Anything that we previously used Bash or Python for - any complex task delegation from GHA; utility scripts for setting up proper ssh tunneling for various k8s clusters; there's pretty complex CLI tool we build for testing our services in ephemeral SDEs running our pods.
Personally: all my MCPs are written in Clojure - https://github.com/agzam/death-contraptions; I write small web-scraping scripts and automations in nbb with Playwright. The flexibility of starting the REPL and figuring out the rest of it dynamically, while poking through DOM elements directly from the editor is some blackmagicfuckery that should be outlawed. Imagine being able to control the state of the web browser while typing some incantations in your editor, without much ceremony, without some crazy scaffolding, without "frameworks", without even having to save the code into a file. You gotta be some ignorant fool who doesn't know this was at all possible or a complete idiot to say "meh, but all these parentheses". You gotta be kidding me. It's like if someone gave you a magic car attachment that makes it run for 800 miles on a single charge and you'd say: "meh, I don't like the color of it"...
Clojure had lousy error messages, agents deal with this well.
Clojure is capable of producing some of the most dense code I’ve ever seen, so manual code reviews really start to feel like a bottleneck unless your goal is to level up.
> Clojure is capable of producing some of the most dense code I’ve ever seen, so manual code reviews really start to feel like
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.
Not to mention that Clojurescript often emit safer code than Typescript does. Sounds insane and counter-intuitive, but here's the thing - Typescript actually removes all the type information from the emitted JS. Clojure, being strongly typed retains the strong typing guarantees in the compiled JS code. So all that enormous amount of effort required to deal with complex types, in practice feels like bringing kata choreography to a street fight - it's not utterly useless by itself, but hardly helping in a real fight-or-flight situation. You can impress the attacker with your beautiful dance and even prevent them from attacking you, but that's more like hope than a real strategy.
I would say dense code tends to help code reviews. It just is a bit unintuitive to spend minutes looking at a page of code when you are used to take a few seconds in more verbose languages.
I find it also easier to just grab the code and interactively play with it compared to do that with 40 pages of code.
I work on a large Clojure codebase with AI, and I'm getting excellent results. Likely factors are code density, the resulting token density, and a lot of well-architected code that the AI can follow — I'm not sure exactly, but the results are really good.
Yeah I see this at work - people are sceptical that AI + Clojure even works
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.
I find it actually the best substrate to write AI tooling. All my custom MCPs are written in Clojure (bb). You hook up the agent to the REPL and let it go wild - it builds something nice. Also, Clojure is one of the most token efficient PLs.
One of the main problems I have with the models coding is the feedback loop is way down the chain from generation, it's out at the commit boundary for python when your hooks are running, maybe at the point where the model wants to push a PR. The REPL lets that happen during generation, and the other safety measures help immensely. Immutable data, STM, all of the features in Clojure that gave devs super powers now do the same for a model.
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.
Not to mention that changes are easier to review, because there is less of them. Same semantic diff for JavaScript and Clojure looks vastly different, and I'll favor to review Clojure changes any day of the week.
You know there's a saying in Russian, that roughly translates to: "an expert surgeon is capable of helping a bad dancer", which is on itself is a reference to another idiom: "a bad dancer always blames his own balls".
That's quickly becoming befitting for cases like this - so often people rush to blame AI without even trying to use their own reasoning. I don't know what to say, hope you find a good surgeon, because it is obvious - you're shit of a dancer.
But that's not some lossless transformation - we've forsaken the beautiful poetry, complex relationship between dancers -> balls -> surgeons. I mean, the point was not to bash on bad dancers, no - I am not a bigot. Bad dancers are an important layer of society; they create good economy for surgeons to thrive. They create supplementary jobs - for every surgeon out there, there's a need for assistants, accountants, janitors, etc. A single bad dancer can feed multiple generations of people.
The very official Clojure page in TFA links to clojure-mcp (written by the person who created figwheel: a famous ClojureScript library in the Clojure ecosystem) and other AI resources related to Clojure.
It's not because Rich doesn't want AI-generated pull-requests by people then taking credits that the Clojure community is anti-AI.
I use Claude Code CLI daily with Clojure, just not in a "write me five thousands lines of Clojure code I won't read" type of way.
I don't think it is, considering they highlighted it in a post about human craft [1]. I read somewhere it was illustrated by felipemelo.net, but can't find the reference anymore
There’s nothing odd about two belts in this situation. One is the belt for the pants and the other is the utility belt holding the pouches. You need to be able to add and remove the utilities without having your pants fall.
The weird choice is having a belt and suspenders. That only works as a fashion choice, which makes little sense for an explorer.
the scarf matches the one Rich is wearing near the end of the documentary. the code matches what's on the Clojure source code, even if it's an odd choice. the two belts are in the draft, even if only one of them features the logo. the artist's instagram has a bunch of well colorized artwork. I believe it is really human made
The BlueSky post has another interesting clue. The pencil sketch on the right. Seems possible a human artist drew the sketch, then had an AI model "colorize" it. And in so doing, maybe the AI model added the 3 genAI tells/artifacts I identified above.
As you demonstrated, AI is not needed to write slop, just because AI is involved doesn't make it slop. We are still very much in the control even if it is generation.
The double belt buckle is a pretty classic diffusion model artifact — it struggles with symmetrical accessories because it's essentially pattern-matching textures rather than understanding "this person is wearing one belt." Same reason you see six-fingered hands.
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.
It was hand drawn by an artist. Indiana Jones (the obvious inspiration) wore two belts, one for his pants, one for his whip/holster. The code was provided by Rich.
Looking back Clojure has been the best thing to happen to me in this industry
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
> 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
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.
I'm probably not the sort of person you're referring to, but I do regularly restart the REPL because
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"
Yes, but without a clean REPL you can't easily be sure that your var definitions are what you think they are.
Sure, so once a week or so you need to restart the process if you end up like that.
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...
The thing that happens to me is that I'll get something working in the REPL, then try to deploy it and it breaks—because unbeknownst to me, I had gotten my REPL into some state where everything was working, but a cold start doesn't look the same.
Is this a skill issue? Absolutely. Do I still restart the REPL frequently (not after every def, but often) just to make sure I'm working with the same environment my program will be experiencing at run time? Yes I absolutely do.
Ah yeah, been there, and probably the first time was when renaming a function but missing to update callers, so callers keep calling the old function, and you have no idea why the changes you made in the new function aren't working.
I have a this little function for clearing the current namespace that I call every time I rename any var inside a namespace:
Not a perfect solution, but personally I also don't know a better solution that doesn't involve loosing out on other (non-negotiable for me) benefits.Couldn't you have one test that requires your -main and runs it?
Just fire that off every now and then?
Basically the same thing, but you don't lose repl state
Once a week?! Aren't you killing the repl at least to run a full test suite without any stale leftover developer state before deploying?
Full test suites I run before committing essentially, in a separate tab altogether, then the full suite is typically also run in CI before any deploys.
> Yes, but without a clean REPL you can't easily be sure that your var definitions are what you think they are.
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).
Been over a decade since I used Clojure in anger, but at the time it really seemed like IDEs made it hard to use a REPL with a large codebase -- they seemed more to want it to be like a javac/maven stack. I assume that got better?
Guess you could say it helped you find some clojure
I am so thankful for Clojure. It enabled me to run a solo-founder business for the last 10 years in a sustainable and maintainable way. It allows me to manage a large complex codebase (client+server) because of low incidental complexity and the fact that the server and the client share most of the business logic code.
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.
In a previous life, I wrote Clojure every day and still look back fondly attending Clojure/Conj and sitting next to Rich Hickey and other Clojure greats at dinner.
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
What are you using now? how do you feel about clojure now?
I’m no longer in a professional engineering position and have a family and toddler so less time for learning about or playing with program languages. Clojure is what really made me first start thinking about programming languages and down the rabbit hole of scala and Haskell and idris and type theory books. Which are incredible and I can’t recommend more and also not remotely practical.
> also not remotely practical.
studying them makes you smarter, which makes you better at using the practical stuff.
It also makes you bitter, at least in my experience.
Completely agree, I guess I meant if you're writing an application you're going to be a lot less productive using Idris.
I love the clojure, but I think a big downside is not being able to use it at work and now work feels like I'm being forced to work with stone age tools in comparison.
Sometimes I think I was happier before I learned Clojure.
I never understood this sentiment. Even if nobody on my team uses Emacs or Vim, or Clojure, Rust, Zig or Nix, or some browser extensions, or any other tool, nobody could ever directly deny me access or restrict the use of any of that on my machine, some vm-box or EC2. And once I prove their usability to me personally, I show that to my colleagues and typically people when impressed they start using them. Once you have more than three people, you can start discussing rolling it out for general use. Just this past year alone, I have convinced my teammates to use a bunch of tools they'd never heard of before.
It's more depressing if you work in a big organization where decisions come down from on-high instead of letting teams decide what's best. (Especially if one of those decisions is so-called Agile practices which were about empowering teams against on-high global decisions from management, but that's a digression.)
But yes, treat it as a job, and make time for "fun time" after work at home using your favorite tools and languages and OSes, and you can still be happy, especially because the bills are being paid. And even in restrictive corporations there still may be opportunities to introduce a little of your favorite thing... Clojure itself "snuck in" at a lot of places because it was just another jar, and it's not too hard to shim in a bit of Java code that then turns things over to the Clojure system. You can also try getting away with internal-only tooling.
If I had stayed at my last job a little longer I would have tried putting more effort into sneaking Common Lisp in. I had a few slackbot tools I wrote in Lisp running on my machine that I turned over (with pre-built binaries) to someone else when I left (but I doubt they're running still). The main application was Java, and there was already mandates from security people and others not to use other JVM languages.. at least in application code. I was thinking (and got a prototype working) of sneaking in Lisp via ABCL, but only for selenium web driver tests. It was a neat trick to show some coworkers a difference in workflow: write or edit a web driver test, one of your asserts fails or an action click on some ID that's not there fails, in Java you get an exception and it's over, you'll have to restart the whole thing, which for us was expensive because these test suites typically spun up huge sets of state before starting. But with Lisp, exceptions don't automatically go back up the stack, but pause at the spot they occurred: from there you can do anything in the debugging REPL that you can do normally, redefine functions, classes, whatever, and then resume the computation from where it left off (or at some higher part of the call tree stack if you prefer), thus no expensive restart.
There's also ways to introduce things you like that aren't just different languages. My team started doing "lunch and learns" at most once a week (sometimes less often); if anyone wanted to talk about whatever for 30-60+ mins during a lunch period we'd get together and do it. Sometimes that would be about specific work things being built, sometimes it would be about external stuff, ideas (e.g. the Mikado Method) or tools. Once I did a brief presentation about property testing and later on got the quicktheories library for Java into the codebase and handling some tests, and ended up not being the only one to occasionally make use of it.
How do you feel about it now? Like holistically.
I miss it. I’m now more removed and building software as a means to an end.
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.
I felt exactly the same, but recently started building side projects again in Haskell and fell in love again. Really brought my passion for software development back. 2026 feels perfect for that, as AI can help with things where one was stuck, not the stuck in a good learning way, forever in the past. Now is the time!
I love the clojure, but I think a big downside is not being able to use it at work and now work feels like I'm being forced to work with stone age tools in comparison. That gets quite depressing sometimes.
Sometimes I think I was happier before I learned Clojure.
Ignorance was bliss.
Incredible: I had not idea NuBank discovered Datomic first and that it's Datomic that led them to Clojure, 100 million+ customers, and eventually acquiring Cognitect.
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:
https://youtu.be/BeE00vGC36E
His talk is presented from Emacs, gotta love that too...
Emacs has always had a tight link with Lisp communities, due to its history, including ties to Lisp Machines, so naturally many use it.
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.
Datomic was the reason I switched [^1] to Clojure as my primary language in 2014. It was a gamble, but it paid off in the end.
I maintain that Clojure is the best AI-first language due to the lightning-fast iteration via the nREPL and Clojure's token efficiency.
[^1]: https://petrustheron.com/posts/why-clojure.html
I don't know if it's still the case, but at old clojure conferences, or meetups, or places of employment, emacs was a prereq and assumed (and the most enjoyable)
I think it was more like Emacs got Clojure development niceties early, particularly tight REPL integration.
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.
Things have been different for well over five years...
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
Thank you Colin for the outstanding work and selfless, continuous gifting and self-generosity. Cursive remains one of the important pillars of Clojure journey for many beginners and seasoned pros.
You just can't ignore the amazing collaboration and camaraderie between Clojure tools builders. - you Colin, Peter (Calva), Eric (clojure-lsp), Michiel (babashka, kondo, etc.), Bozhidar (CIDER, clojure-mode), Juan (flowstorm), Chris (Portal), and many others.
Everyone, instead of competing with one another just wants for people to find their best way of using Clojure, and that is really awesome. You can see the ideas freely circulating between spaces and creating great of awesomeness for everyone in the community. I'm telling you all this as someone who doesn't even use Cursive. I still can see your work. I can tell how valuable, important and vital you are for me personally and for many of my friends and colleagues. I salute you, and every other tool-making hero. Thank you, guys!
Thanks! Yes, I get on really well with everyone in the community - the community in general is perhaps my favourite thing about Clojure!
Cursive has been way ahead of the curve, yes. Sorry Colin, I'm both emacs-addled and fuzzy with timelines :D
So think of it more like "static analysis stuff for the rest of us" :D
Hehe, Lisp Emacs Myopia is indeed a real thing. Cursive users have been not starting REPLs for over a decade now!
j/k of course, and no offence taken :-)
[dead]
I’ve been using Clojure since 2013, and can say that it has been an enormous positive force in my life. I’ve been a very unorthodox user, most of my artworks were built using Clojure in some way. But I’ve also worked in industry, and there I think Clojure helped me avoid burnout on more than one occasion. Especially when running a startup built half on it :)
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.
I'm not sure what you use ti for, but your website is beautiful and your work is really striking.
Thank you! I’ve managed to shoehorn Clojure into everything from 3D model generation to VR networking servers for installations :D It makes so many things easier to reason about!
Very cool. Anything open source/on github?
I wish I had a chance to open source. So much of it was done in mad hacking sessions to glue things that were never supposed to work together. Or contain all the secret sauce for one work or another. Maybe the next one!
makes sense. I'll keep an eye on your site.
Clojure is my favourite alternative language on the JVM, besides offering what Lisps have provided for decades, their philosophy of embracing the host platform, instead of all the talk that the next JVM will be rewriten in it like some others do, makes being around Clojure folks much more appealing.
When I was younger this actually irked me a bit. I wasn't familiar with either, so it felt burdensome to me. The tooling also wasn't as good as it is now.
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.
Clojure is a great language and ecosystem. I donated a little money to Rich's efforts in the early days (I loved his older Common Lisp - Java bridge so his Clojure project was immediately interesting) and I have been paid for a few years of Clojure development.
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.
What made you stop using Clojure or not so much anymore? No jobs in Clojure?
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?
I used tools that I was paid to use. After being deep in neural networks in the 1980s, ten years ago I dropped back into deep learning, thus mostly used Python.
> what is stopping it from being more widely adopted.
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?
Thanks for sharing your thoughts. Haven't seen it from that perspective yet.
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.
> Or is the reality that Clojure put you ahead back in the 2010s, but in 2026 it only offers marginal business value and benefits.
How so? Yes, some ideas from early Clojure have leaked into the mainstream, yet "absorbed some FP-flavored features" is not the same as "delivers Clojure's value proposition". Let's examine the proposition: "a language where I can iterate on domain logic at REPL speed with immutable data and good concurrency on a mature runtime", what does fit this description today?
- Elixir is the closest thing. Immutable by default, pattern matching, excellent concurrency, What we'd lose? Homoiconicity and macros of the same level, the host-interop story, data-orientation as a philosophy.
- F#. Immutable by default, discriminated unions, computation expressions, nice REPL, hosted on a mature runtime with full ecosystem access. Statically typed, which is a different tradeoff. What you lose: dynamism, macros, the Lisp sensibility, cljs-style multi-host story.
- Elm/Purescript in the frontend niche. Immutable, functional, good at what they do. Neither is a Clojure replacement because neither is a general-purpose platform play. Elm is effectively frozen. Purescript is healthy but tiny.
- Gleam on BEAM. Typed, functional, growing fast. Too young to be a replacement today, worth watching.
- Scala. I'd argue it shouldn't even be in the category despite the surface similarity. It's a different philosophy (types-first, expression-oriented, complex type system) and the REPL experience is not comparable. It competes with Clojure for "the non-Java JVM job" but not on value proposition.
- Kotlin. Even further from the category. Pragmatic Java-plus. Wins jobs Clojure might have won in 2015 but for reasons of "looks like Java, hires like Java" rather than matching Clojure's model.
- Before you say what seems to be everyone wants to scream about - Rust/Zig and Clojure solve almost disjoint problems, which is the first thing to say out loud when someone uses one to dismiss the other. I can dive into the details, if you insist, but I think this isn't the category for it.
The real answer to "is there a replacement": no single language hits all of (hosted + dynamic + homoiconic + persistent data + REPL-driven + multi-host via .cljc). Elixir hits most of the development-model points but throws out the multi-platform story and the Lisp. F# hits the runtime maturity and immutability but throws out dynamism. Everything else is further. What you actually see is Clojure holding a small, stable, well-compensated niche. And it's holding it like a champ - it offers real, practical, sensible benefits where every other stack have no similar alternatives for.
But the bigger point is that doing this kind of shallow comparisons is vain, because you really need to understand every language holistically - every language has strong points and weaknesses that manifest in certain scenarios, for certain domains, teams, different constraints. Clojure remarkably fits well more often than it doesn't. More importantly, the model and the ideas that the language promotes fit elegantly, even when you're not writing Clojure.
I enjoyed both of your long comments, thanks!
I would add one thing to the programming languages conversation: which languages make developers happy to use them? Personally, I have no emotional involvement with Python (sometimes the practical choice, but no excitement). I love using Lisp languages, and enjoy Haskell even though I am not a particularly good Haskell programmer.
> How so?
I don't know, hence my question.
See Mark's comment above. ML expert, wrote a book about ML for Clojure, but it seems he had to stick to Python, since that's where the ML jobs are. I've read a few times now that Clojure folks think it's much better suited for ML projects and yet Python has 'won' in the marketplace.
I'm just trying to understand why Closure hasn't caught on. It's marketed as a general purpose language, has all these amazing benefits, amazing community but now it's niche and adoption seems to be slowing and that's a shame.
So hopefully this documentary will help to increase adoption. Because I think we can agree it would be nice to see more Clojure jobs.
But what else can be done? Does it need better marketing? Better on-boarding for beginners?
Or is it futile because most newcomers and tech leads won't want to invest the effort to get over the initial bump of a steeper learning curve and see smaller ecosystem as a downside?
Hey other Mark Watson ( ^_^)／
Excellent. The only thing I wish they had added was borkdude.
Yes, sad there's no European presence (unless I missed someone). There's tons of Clojure over there. Metosin, Juxt, Borkent, Gaiwan (Arne), Flexiana, Peter Strömberg (Calva), Dustin Getz (hyperfiddle/electric), Christophe Grand (ClojureDart), Bojidar (CIDER), Renzo, and many, many more.
I agree. Probably a cost issue as all interviews appear to be done in person.
They could've cut Zoom interviews in there - they are not expensive. The documentary creates a skewed image of Clojure being mainly in Americas, while in fact the big chunk of it is on the other side, where they have more conferences, (probably) more startups and (perhaps) people using it.
I am pretty sure Dustin Getz is American.
Oops, my bad. Someone on hyperfiddle/electric core team is in Europe, I think, but now I'm not sure about that either.
Oh wow, that's indeed a bit weird.
didn't know datomic was free of licensing fees - I didn't use it back in the day because the cost was prohibitive... interesting
It is!
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/
the "stable long-term companion" framing from jwr's comment is the part that sticks with me. every company I've worked with that chased the new shiny ended up spending more time on migrations than on the actual product.
stability is boring to talk about but it's the thing that actually lets small teams survive long enough to win.
I've always enjoyed using Clojure. Unfortunately, most of the things I do require interacting with the C world, so it has never been a real option as my primary language.
You might be interested in https://jank-lang.org/ - still early days but full C/C++ interop is the plan.
Coffi [1] built on java 22 (project panama) C FFI. Makes binding to C from Clojure a lot of fun.
- [1] https://github.com/IGJoshua/coffi
Have a look at Janet. It is not as powerful as Clojure but for smaller projects, prototyping, scripting etc., it is really enjoyable.
https://janet-lang.org/
I also interact a ton with C and C++, but it's easy today to have Claude write a Project Panama wrapper and then put a nice Clojure veneer on top of the Java.
Interesting, how many ex-users of Clojure are in the comments. Everyone is praising it, but also everyone moved to something else?
Less ex-user, more like: never really managed to get to use it at work I guess (just like it is for me). It is still a niche language (compared to the big ones) after all.
It’s a real statistical outlier, nearly every language people have moved on from gets negative reviews. Me, it was fun but it wasn’t for me and eventually I concluded a number of the fundamental design decisions were wrong.
Can elaborate which design decisions were wrong and why in your view?
Here’s one: Mike Rettig wrote a great post about this in the early days, long since lost to time. Didn’t take that much note of it at the time but grew increasingly convinced over time: shared memory primitives are a bad idea. We would have been better off with an architecture that prioritised message passing. (Not that you can’t do message passing in Clojure, just that it isn’t privileged the way STM is.)
Can you expand on that a bit? What language do you use now?
These days, it’s mostly C#. It’s got one of the most sophisticated list processing modules of any language I know of, you can fairly easily write heavily immutable code. It’s a bit niche because Microsoft but it’s nonetheless solid.
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!
is clojure still relevant in the post agentic coding reality that opens up pretty much all esoteric languages to everyone ?
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
Clojure is more relevant than ever in post agentic coding because of immutability and the REPL. The two big problems with agentic coding is context growing in unbounded fashion, and agents being able to get quick feedback on what they're doing. Mainstream languages fail on both accounts. I've found Clojure has been a great fit for keeping agents on track.
I've wrote about this in more detail here if you're interested https://yogthos.net/posts/2026-02-25-ai-at-scale.html
Clojure might be the least esoteric language ever. Call a function, get a value.
It definitely is more "mainstream" than others but I just don't see the same level of attention and enthusiasm around it anymore. I'm sure it is still being used in many places but like Elixir, hiring remains on the tough end.
Hiring good talent was always problematic. This has nothing to do with the quality, capacity, and robustness of the language or its relevance. Hiring people who would love to use Clojure but have no prior experience is not that difficult - it's just that every company wants an expert, but they don't want to offer expert salaries. In places where they do, the competition is nuts, on top of that, experienced Clojuristas typically get interviewed and scrutinized with the same level of rigor as architects.
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.
I've had Clojure on my resume for 10 years, mainly to see if anyone would ask about it. Nobody ever has, until an interview a couple days ago. We'll see if it actually helps in leading to an offer, I guess.
I have the opposite experience - been using Clojure for over a decade and it feels like only that mattered for the last five jobs. Even though it's really only just one of many layers that required to do the job. I honestly would love to find a non-clj team and convince them to use it. There are so many useful scripts we write in babaska alone, it just sounds wasteful not to use that path, fully knowing of its existence.
Can you talk more about those scripts, what are you using it for?
Imagine what you'd use random shell scripts, Makefile/Justfile or whatever "scripts" the language offers, if any, but written in Clojure instead, run with Babashka.
Anything that we previously used Bash or Python for - any complex task delegation from GHA; utility scripts for setting up proper ssh tunneling for various k8s clusters; there's pretty complex CLI tool we build for testing our services in ephemeral SDEs running our pods.
Personally: all my MCPs are written in Clojure - https://github.com/agzam/death-contraptions; I write small web-scraping scripts and automations in nbb with Playwright. The flexibility of starting the REPL and figuring out the rest of it dynamically, while poking through DOM elements directly from the editor is some blackmagicfuckery that should be outlawed. Imagine being able to control the state of the web browser while typing some incantations in your editor, without much ceremony, without some crazy scaffolding, without "frameworks", without even having to save the code into a file. You gotta be some ignorant fool who doesn't know this was at all possible or a complete idiot to say "meh, but all these parentheses". You gotta be kidding me. It's like if someone gave you a magic car attachment that makes it run for 800 miles on a single charge and you'd say: "meh, I don't like the color of it"...
I think this would be a great candidate for some short video clips to illustrate the power of CLJ / CLJS.
As per our other thread... what can be done to increase adoption.
Clojure had lousy error messages, agents deal with this well. Clojure is capable of producing some of the most dense code I’ve ever seen, so manual code reviews really start to feel like a bottleneck unless your goal is to level up.
> Clojure is capable of producing some of the most dense code I’ve ever seen, so manual code reviews really start to feel like
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.
Couldn't agree more. And I actually kind of like Typescript, but man, typical Typescript projects are so verbose and sprawling, it's crazy.
Not to mention that Clojurescript often emit safer code than Typescript does. Sounds insane and counter-intuitive, but here's the thing - Typescript actually removes all the type information from the emitted JS. Clojure, being strongly typed retains the strong typing guarantees in the compiled JS code. So all that enormous amount of effort required to deal with complex types, in practice feels like bringing kata choreography to a street fight - it's not utterly useless by itself, but hardly helping in a real fight-or-flight situation. You can impress the attacker with your beautiful dance and even prevent them from attacking you, but that's more like hope than a real strategy.
I would say dense code tends to help code reviews. It just is a bit unintuitive to spend minutes looking at a page of code when you are used to take a few seconds in more verbose languages.
I find it also easier to just grab the code and interactively play with it compared to do that with 40 pages of code.
I work on a large Clojure codebase with AI, and I'm getting excellent results. Likely factors are code density, the resulting token density, and a lot of well-architected code that the AI can follow — I'm not sure exactly, but the results are really good.
Yeah I see this at work - people are sceptical that AI + Clojure even works
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
> mis-matched parens
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.
I find it actually the best substrate to write AI tooling. All my custom MCPs are written in Clojure (bb). You hook up the agent to the REPL and let it go wild - it builds something nice. Also, Clojure is one of the most token efficient PLs.
One of the main problems I have with the models coding is the feedback loop is way down the chain from generation, it's out at the commit boundary for python when your hooks are running, maybe at the point where the model wants to push a PR. The REPL lets that happen during generation, and the other safety measures help immensely. Immutable data, STM, all of the features in Clojure that gave devs super powers now do the same for a model.
Personally this is a hidden trick I use.
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.
Not to mention that changes are easier to review, because there is less of them. Same semantic diff for JavaScript and Clojure looks vastly different, and I'll favor to review Clojure changes any day of the week.
Autochrome [0] make reviewing Clojure diffs from AI really easy.
[0] https://github.com/ladderlife/autochrome
I would say with the nREPL feature and letting the AI Agent jack in, Clojure may actually be the most well positioned language for this use case.
This is like asking if violins are still relevant because we have cars now.
[dead]
[dead]
[flagged]
You know there's a saying in Russian, that roughly translates to: "an expert surgeon is capable of helping a bad dancer", which is on itself is a reference to another idiom: "a bad dancer always blames his own balls".
That's quickly becoming befitting for cases like this - so often people rush to blame AI without even trying to use their own reasoning. I don't know what to say, hope you find a good surgeon, because it is obvious - you're shit of a dancer.
"A good craftsman doesn't blame his tools" might be the western equivalent.
But that's not some lossless transformation - we've forsaken the beautiful poetry, complex relationship between dancers -> balls -> surgeons. I mean, the point was not to bash on bad dancers, no - I am not a bigot. Bad dancers are an important layer of society; they create good economy for surgeons to thrive. They create supplementary jobs - for every surgeon out there, there's a need for assistants, accountants, janitors, etc. A single bad dancer can feed multiple generations of people.
The very official Clojure page in TFA links to clojure-mcp (written by the person who created figwheel: a famous ClojureScript library in the Clojure ecosystem) and other AI resources related to Clojure.
It's not because Rich doesn't want AI-generated pull-requests by people then taking credits that the Clojure community is anti-AI.
I use Claude Code CLI daily with Clojure, just not in a "write me five thousands lines of Clojure code I won't read" type of way.
Are you watching the same thing I am? What AI slop?
I think they mean the video thumbnail, which may or may not be AI-generated.
I don't think it is, considering they highlighted it in a post about human craft [1]. I read somewhere it was illustrated by felipemelo.net, but can't find the reference anymore
[1]: https://bsky.app/profile/cultrepo.bsky.social/post/3mjhubrh3...
It'll be interesting to learn whether it was AI-generated. It certainly SEEMS like it is. It has a few "tells":
- two belts and two Clojure logo belt buckles
- same code repeated on the steps (odd artistic choice if made by the artist)
- the seemingly out-of-place scarf, stylistically its color/pattern doesn't seem to fit
Either way, it seems like an homage to this Indiana Jones and the Temple of Doom poster:
https://www.slantmagazine.com/wp-content/uploads/2008/05/tem...
There’s nothing odd about two belts in this situation. One is the belt for the pants and the other is the utility belt holding the pouches. You need to be able to add and remove the utilities without having your pants fall.
The weird choice is having a belt and suspenders. That only works as a fashion choice, which makes little sense for an explorer.
the scarf matches the one Rich is wearing near the end of the documentary. the code matches what's on the Clojure source code, even if it's an odd choice. the two belts are in the draft, even if only one of them features the logo. the artist's instagram has a bunch of well colorized artwork. I believe it is really human made
Huh. I don’t doubt you, but I guess this is a sign pervasive AI/LLM generative artwork is messing with my brain’s pattern matching at a deep level.
That wouldn't be very interesting at all. It's just a thumbnail on a niche programming documentary
The BlueSky post has another interesting clue. The pencil sketch on the right. Seems possible a human artist drew the sketch, then had an AI model "colorize" it. And in so doing, maybe the AI model added the 3 genAI tells/artifacts I identified above.
Rich commented in one of the comments under the video pointing the same thing and he says it is not AI generated
At least the cult repo folks said on LinkedIn that it is not, which tbh is surprising.
https://www.linkedin.com/posts/emmalouisetracey_one-of-my-fa...
As you demonstrated, AI is not needed to write slop, just because AI is involved doesn't make it slop. We are still very much in the control even if it is generation.
The double belt buckle is a pretty classic diffusion model artifact — it struggles with symmetrical accessories because it's essentially pattern-matching textures rather than understanding "this person is wearing one belt." Same reason you see six-fingered hands.
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.
It was hand drawn by an artist. Indiana Jones (the obvious inspiration) wore two belts, one for his pants, one for his whip/holster. The code was provided by Rich.
According to the documentary group it was hand drawn:
https://www.linkedin.com/posts/cult-repo_call-us-old-fashion...