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

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