I miss the days of having a native desktop design app with a perpetual license.
What Figma achieved technically in the 2010s was amazing. Coded the app in C++ and then used WASM to deliver it as a multiplayer web app.
But now it's trying to be too many things. Why did they ever feel the need to add slides and this other stuff.
Their MCP is poor (sure, they'll improve it).
The app struggles with larger files and performance is sloppy.
And don't get me started trying to design data grid heavy apps.
And they could easily follow Adobe's lead. Enshittify and lock you out of your account whenever they feel it's necessary (remember what happened with Venezuelan Adobe users a few years ago?)
Either Penpot gets their act together and will become the opensource design canvas for open-weight AI models or we will see another open source solution that will fill this space.
> I miss the days of having a native desktop design app with a perpetual license.
You can go that route with Affinity Designer [1], owned by Canva, who partnered with Anthropic on Claude Design [2]:
We’ve loved collaborating with Anthropic over the past couple of years and share a deep focus on making complex things simple. At Canva, our mission has always been to empower the world to design, and that means bringing Canva to wherever ideas begin. We’re excited to build on our collaboration with Claude, making it seamless for people to bring ideas and drafts from Claude Design into Canva, where they instantly become fully editable and collaborative designs ready to refine, share, and publish.
I have it, jumped on the affinity band wagon years ago after Adobe started their enshittification process.
After Canva bought Affinity, you now have to authenticate with your email from time to time when you launch the desktop app. Annoying and why do they do that?
They have to operate within the laws of the countries they’re physically located in. Those countries want to know that they’re not hosting illegal content, providing services to crime rings, Russia or North Korea, etc.
If Hetzner allows you to host something and you use it for illegal acts, they aren’t going to jail to shield you for €10/month.
Hetzner is like 1/10th the cost of ripoffs like AWS now, the passport data is deleted after verification and I can actually trust this claim coming from an EU company under GDPR that doesn't have any use for my personal data. You can also just bypass the passport requirement entirely by making a €20 Paypal deposit to the account.
You just hear too many horror stories of data being leaked. Even if Hetzner uses a 3rd party system to do the verification - that 3rd party probably has to store your pics for some time.
But at least if there is an alternative then great.
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.
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 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.
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"...
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.
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.
> I don't understand though why reader mode is not always available. The text is there.
Mostly because we don't have any standard markup to say "this is the content". Which means reader mode has to guess which tags contain the content, and this whole thing boils down to a pair of regexps[1]
I don't know much about the factors that determine why one AI coding harness is better than others. Is it system prompts? Or just personal preference in terms of the UX and there isn't actually a better output between using CC or Pi?
So what makes Pi better than CC? Is it better than OpenCode?
My experience with harnesses is entirely about UX, personally. You could just use an LLM directly and pipe its output directly into your source files, but that would produce terrible results in practice. Harnesses / agents are just better versions of “curl https://llm.com > source.{py/js/cpp/etc}”, imo
Long term I’m bullish on an open source harness “winning” the foot race, in a similar way that Linux “won” over Windows and MacOS (that is, debatably)
You mention the client-server architecture of opencode. Is that a local server or is it calling home to opencode servers?
One of the ideas I like about opencode is the ability to prompt and such from a web browser. So I'm curious if that is the client-server architecture you are talking about, or if it's something else.
For reference, I used replit for some vibe-ish coding for a little bit and really liked that I could easily prompt and view output on my phone when hanging out away from my computer. Or while waiting at the airport for example.
(RIP OG replit by the way. They've pretty much completely pivoted from a REPL to AI, which is pretty hilarious to me given the company name xD)
> One of the ideas I like about opencode is the ability to prompt and such from a web browser. So I'm curious if that is the client-server architecture you are talking about, or if it's something else.
Yes, this is what I meant. And yes it's ok that you like this about opencode :)
> For reference, I used replit for some vibe-ish coding for a little bit and really liked that I could easily prompt and view output on my phone when hanging out away from my computer. Or while waiting at the airport for example.
I use Google Jules and also appreciate being able to nudge it forward when not at the computer. In general I often appreciate when things run on other people's machines. However, if I'm to run a thing on my machines, it better be minimalist!
The harness or the tool is ok but all the defaults as part of the paid pieces of the tool have really bad privacy decisions. So they offer Zen as a pay as you use credit system with access to the models they think work best with the harness. Their own stealth model in it along with a number of the leading new models are always-on sharing data for training purposes. They don’t make this immediately obvious either you have to click through links on their website to see the breakdown.
I am not usually super privacy minded but if you already made it nonobvious this is happening I don’t really trust the underlying tool.
Above is the link. The front page says your privacy is important and says they don’t do training on your data except for the following exceptions which links to this page. Then even their own model is training on your data except there is no opt out. So if you pay for zen and you select one of these models in the tool you have no clue it’s auto training on your data.
Your blog is a treasure trove - thanks for sharing.
Do you still cut your own hair ;) ?
But yes us folks in the creative world can learn a few things from the corporate world when it comes to contracts and payment schedules. Mike Monteiro's talk 'F*ck you, pay me' comes to mind.
What Figma achieved technically in the 2010s was amazing. Coded the app in C++ and then used WASM to deliver it as a multiplayer web app.
But now it's trying to be too many things. Why did they ever feel the need to add slides and this other stuff.
Their MCP is poor (sure, they'll improve it).
The app struggles with larger files and performance is sloppy.
And don't get me started trying to design data grid heavy apps.
And they could easily follow Adobe's lead. Enshittify and lock you out of your account whenever they feel it's necessary (remember what happened with Venezuelan Adobe users a few years ago?)
Either Penpot gets their act together and will become the opensource design canvas for open-weight AI models or we will see another open source solution that will fill this space.
reply