I agree and I am amazed at how much money some individuals and also a friend's company burn on token costs. I get huge benefits from this tech just using gemini-cli and Antigravity a few times a week, briefly. I also currently invest about $15/month in GLM-5.1 running Hermes Agent on a small dedicated VPS - fantastically good value for getting stuff done and this requires little of my time besides planning what I need done.
I think the token burners are doing it wrong. I think that long term it is better to move a little slower, do most analysis and thinking myself, and just use AI when the benefits are large while taking little of my time and money to use the tools.
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?
I find OpenClaw and (more so) Hermes Agent useful for software development, research, and writing - but I refuse to run them anywhere that is not deeply-sandboxed and has no access to most of my digital life data.
OK, everyone makes their own decisions re: privacy and security. Personally, I am comfortable running OpenClaw and Hermes Agent on a rented VPS (preferably in a docker container on a VPS) and allow limited access to (some of) my GitHub repos. Both tools are useful, even in such a limited mode of operation. I just don't see value vs. risk allowing access to email, messaging apps, access to my personal computer, etc.
It is close to zero overhead to SSH/Mosh to a VPS, get inside a container to work. Why risk infecting your personal or corporate computer?
At the time his friends and family in interviews talked about how happy he was: after whistle blowing and leaving to start his own company. The scary thing is that there were so many huge investors who might have had him killed. People are weird when there is a lot of money involved.
Funny how epstein’s supposed suicide occcured when cameras failed hmmm.
I think people underestimate what certain people will do - you don’t make it to the top nor acquire a lot of wealth without having certain urges. The kinds of urges where you are happy for someone to be terminated as long as you can achieve your goals.
I agree. At first I was really turned off by the Gemma 4 line of models because they didn’t function with coding agents as well as the qwen3.5 line of models. However, I found that for other use cases Gemma 4 was very good.
EDIT: I just saw this: “”Ollama 0.20.6 is here with improved Gemma 4 tool calling!”” I will rerun my tests after breakfast.
That would be my question also. I like it when companies have easy to sign up for, pay as you go models. Being able to buy $5 worth of tokens and get an API key - in less than a few minutes - is ideal.
What you are suggesting might sound difficult to some people, it is possible: in the last week I co-wrote (with Antigravity with Claude as the backend) an Emacs package for agentic coding that also just uses ‘rg’ for finding relevant code for the context, call out to a model, and handle creating a diff with merging tools. I love using my own code that provides inside Emacs vibe coding and I would suggest others try building the same thing.
reply