> That is because Clojure is done

First of all: Clojure is not "done". Latest commits were 3 months ago - https://github.com/clojure/clojure. Secondly, the language intentionally not a batteries-included PL. The core is meant to be a stable, minimal substrate. Most action happens in libraries and tools - core.async, spec & malli, babashka, nbb, etc. Check the activity in Clojurians Slack. It's a small but unusually vibrant community, every single day there are news and announcements - updates, etc. It is done-ness in the good sense - like a well-designed tool that doesn't need to keep changing its handle.

> market share adoption kind of shows it

NuBank being the world's largest digital bank and running Clojure at scale is not "adoption"? Besides, there's Apple, Cisco, and tons of smaller companies running on it.

> there is hardly anything being done

They are making a documentary https://www.youtube.com/watch?v=JJEyffSdBsk Please don't say: "well, there are documentaries about dinosaurs" or something. I've been using Clojure for over ten years - in different teams, companies, industries. For my own projects and professionally. I've heard about it "dying" back then. I keep hearing about it dying every year and I promise you - nothing like that (even remotely) happening. Yes, the hype is gone (was it ever real?), but the language, community, library ecosystem, tooling - all of that only getting better.

There's no "killing" of Lisp. As long as programming languages remain relevant, there will always be some Lisp-dialect around. It probably never will become mainstream, yet it never completely disappears. There's no killing of Lisp, because it would be like killing "graph theory" or something. Graph theory doesn't need a Fortune 500 company funding it to remain true. Similarly, a small community keeping a Lisp dialect alive is all it takes - and there will always be people drawn to the clarity you get when you strip a language down to its lambda-calculus bones and see the whole thing fit in your head at once.

Rich Hickey has made this point himself - Clojure isn't trying to be the most popular language, it's trying to be correct about certain things. And correctness doesn't go out of fashion.

That's a pretty far cry from "complexity is unavoidable". Reading that to me implies that the complexity is inherent in programming language design, whereas this follow-up argument seems to say that complexity is the result of tacking on new features.

The latter is a bit tautological, since the size of the language grammar is itself a measure of complexity.

The current market share shows how far you can go with just being a better Java.

If (or when? I haven't checked recently) a decent and well-thought-out LLVM backend emerges for it, ideally with some new underlying complexity seeping through, the market share might expand overnight.

And as for C++, while some complexity is certainly unavoidable, a rigorous complexity control is desperately needed. Ideally, the same way Bell Labs folks did when they initially conceived Go from Algol68 and C and similar (before or after joining Google; I couldn't tell), and Rich Hickey did when he initially designed Clojure. Some people are managing the complexity using style guides and clang-tidy checks. Which is great in that doing so doesn't need lengthy language committee decisions. But that approach hasn't been enough to make code _sufficiently_ safe; every now and then an enterprising engineer or team finds a way to abuse a feature in a way that produces unsafe or unpredictable results. Rust is a bit better and solves a few of the common problems, but sadly the list of potential issues (of using Rust in a codebase at scale; Engineers' faults, not Rust's) is long and growing. My verdict is we need both complex and simple LLVM languages, ideally co-designed to have no interop problems by design, while allowing expressing some logic in the simple parts and some logic in the complex parts. Or better, a 3 tier design would be nearly perfect: expressive config language, glue and research language, and core building blocks language. I think a clojure-style language can be designed to achieve all three.

> That is because Clojure is done

Yes, that's one approach to avoiding ever growing complexity, maybe the other languages should try it sometime ;)

With that said, everything around Clojure keeps improving and getting better. While the language doesn't have static types, clojure.spec offers something that is even better than static typing (imo), and doesn't even require any changes to the core language. Something else other mainstream languages could learn too.