> 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?

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.

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!

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.

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.

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.

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.

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.

I regret stumbling on Clojure around 2012-2013. I had every chance to learn and work on a big Clojure project with very knowledgeable people yet I looked dead in its eye, right between the parentheses and confidently said: "no, thank you!". It took me a few more years of enormous struggle with Javascript, and after exhausting my options, trying Typescript, Coffeescript, Livescript, Gorillascript, IcedCoffeeScript, Fay, Haste, GHCJS, Elm to finally arrive on Clojurescript. Even though I was dealing with frontend at that time, I already had good experience, and had gone through other stacks: .Net - C#, F#, VB; Python; Haskell; Objective-C; ActionScript; Delphi; some other lesser-known things.

I remember my initial confusion, but it didn't take long when I suddenly felt flabbergasted - shit just made sense. It was so down-to-earth, inexplicably pragmatic and reasonable that it made me want to learn more. I didn't even build anything with it, I was just browsing through related Google search results when I saw "Clojure/Remote Conf" announcement. It was a no-brainer - I took a day off and joined from my home computer. I immediately became a fan-boy. The amount of crazy awesome stuff I saw, the people I met in the chats, the articles and books I put in my notes - all that made me feel excited. After the conference I sat in my chair staring at the blank screen, for 40 minutes or so. Thinking, meditating, contemplating if that was a mid-career crisis or something. Knowing that on Monday I would have to go back to the same struggle, same shit, same mess that I had for the past two years, everything that until this very point made me feel depressed. On Monday I went back to work and said I'm leaving because: "I saw things I cannot unsee". I just knew I could never sneak-in some Clojure there. So I left. Even though it was well-paid job, fifteen minutes away from my home.

Getting into Clojure radically re-opened my eyes to the entire concept of computing. Not only had I found a different way of programming - I felt so enlightened, and largely thanks to the people I met in the community, which deserves special acknowledgment. Clojurians are just made different - they are the kindest, extremely knowledgeable, tolerant and most sincere professionals I have ever met. Not a single time when I asked them a question - no matter how dumb, provocative, or confusing it was; they always, every single time gave me much deeper and thought-provoking answers than I ever expected. None of my inquiries were ever dismissed, ignored or rejected. They'd gladly discuss just about anything - no matter the language, tool, technique, or ideas. Whatever helps you to find answers or get closer to the solution. I know, I have become a better programmer, thanks to Clojure. Yet more importantly, it helped me to become a better person.

Yes, I regret stumbling on Clojure. I wish I never saw it when I wasn't ready for it. It makes me feel sad for the time I have wasted. I wish I had someone persuasive to convince me to learn it sooner. Thank you Rich Hickey and Clojure community for inspiring the fire I didn't even know I had in me.

> Homoiconicity anyone?

I'm just leaving this here for anyone interested, seems relevant: https://github.com/replikativ/ansatz

Ansatz is a verified programming library for Clojure built on the Calculus of Inductive Constructions (CIC) — the same type theory that powers Lean 4.