Some thoughts:

1) Clojure is stable and there will never be big news or big changes to the core language. It's simple in the objective sense. There's fewer patterns to learn, hence less to talk about online. The code I wrote 12 years ago still works. The books I bought 12 years ago are still relevant. To an amateur github star gazer looking only at the metrics from the past month, this looks like stagnation. To me, this looks like good engineering.

2) The can-do pragmatic attitude meshes very well with entrepreneurs and small teams writing proprietary applications that need to get things done. These are NOT the people evangelizing and marketing open source tools. Clojure's successes are private, small, and quiet. In general, there is little to no focus on external validation.

3) Clojure is unabashedly a tool for experts. Don't get me wrong, the community is amazingly welcoming to newbies (as I discovered). But in order to align with Clojure's value proposition, you need to understand the problems it solves and feel them deep in your bones. If the words "mutable state" mean nothing to you, Clojure is going to feel wierd.

These conspire to make Clojure less visible online. Clojure's core audience, expert programmers who focus on outcomes and stable code, they do not read or write SEO blog spam.

The trending technologies, those that change so much they require articles like "How to do X in Y in April 2026" are built on shaky foundations. Trending means churning. That's hardly a value worth chasing.

Thanks for sharing your thoughts.

Since NUBank literally built a billion dollar business because of Clojure, I would have thought the adoption in fintech at least would have been bigger.

Maybe it's because CTOs are just not sure and feel safer for adopting a 'nobody got fired for choosing IBM' mindset.

Maybe it's not important that Clojure needs to grow its ecosystem.

And consequently the company needs to continue building its own adapters and SDKs to use existing commercial and open-source solutions (e.g. in data and observability), because Clojure and Datomic are almost never supported out of the box by any tools. That's a cost added that may not always be justified, because anything related to Clojure and/or Datomic is going to require bespoke integrations.

Not to mention that hiring is a problem because the Clojure market is relatively small. But that's not the reason the language never caught on. Perhaps only a reason companies rarely choose it.

> And consequently the company needs to continue building its own adapters and SDKs to use existing commercial and open-source solutions (e.g. in data and observability), because Clojure and Datomic are almost never supported out of the box by any tools.

But Java almost certainly is. Why not just use the Java stuff? All of the Clojure I've worked on (especially in the data space) has made use of a ton of Java SDKs and libraries.

As I tried to explain above, Clojure is made for a specific set of problems. Your problem seems to be interop with the SDK of the month and hiring. My problem is mutable state. It's logical that we'd choose different solutions.

A pure Clojure stack is extremely rare in most organizations. And integrating data from microservices with data lakes and observability platforms is not "SDKs of the month" but a normal business concern.

What I am trying to say is that immutable state may be one aspect of something much larger that did not factor into Nubank's original decision to use Clojure for microservices. It may have clear benefits there (and in your case - I don't deny that), but downstream you pay for that rarity by having to build every integration yourself.

Couldn’t LLMs help with writing those glue components? Read the doc for the SDK of the month and then write the Clojure interface for it?

The same goes for existing micro services, no?

I like the immutability thing and there is certain kinds of code for which it is genius but I would say you lose a factor of two or so in performance relative to mutable data structures. You might say that it is a small price to pay but people who care about performance feel differently.

I think also Python just has the whole ecosystem for ML work, like so often I can just

  uv install whatever

and I am working with very powerful models on my GPU: part of that is that Python has a C FFI which is easy to work with to integrate the latest numerical and ML libraries and the other path it is all stacked up in easy-to-use packages -- a non-professional programmer can use scikit-learn and pandas and matplotlib to put their skills on wheels.

Python is also a better language for metaprogramming and advanced programming. Like if you look at Graham's On Lisp my two takeaways are: (1) if we was using Clojure instead of CL he would not be fighting with nconc, and (2) almost all the examples in the book can be worked in Python without macros except for the thing where they build an async system for CL and... Python has an async system built in.

Similarly you can implement the stuff in Norvig's book Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp in Python pretty easily. Performance for branchy "old AI" tasks like rules engines and the semantic web is inferior in Python compared to the JVM but actually it is not so bad if you use PyPy.

>Is it really just about the parens?

Probably not the only reason, but certainly a big factor. I'm assuming Clojure is still tied to Java and JRE? It would probably make sense to make a list of languages that have "caught on" or at least those that are currently still "on". Is Ruby (still?) in the "on" category?

For me the JVM is a selling point. Threads that really work and a good garbage collector for instance.

I wonder if Java usage is increasing or decreasing in 2026?

You should split this question in two: - is JVM usage increasing or decreasing in 2026 and - is Java usage increasing or decreasing in 2026

JVM usage (which is the main host for Clojure) as a platform is increasing modestly, driven by modernization (Loom, GraalVM, Valhalla on the horizon)

The organizations that I've worked for for the past 20 years have mainly used either .NET or the JVM for the back end. Some of these were startups and others have been around almost 80 years. On the JVM it has usually been Java but sometimes Scala.

I know there are organizations that use Go or Node but I think you can still get work using the JVM.

Many people use it in ways that have no ties to the JVM - ClojureScript on the web, Babashka for scripting, ClojureDart for Dart apps, etc.