Surprised to see Clojure/ClojureScript come up on socials more often all of a sudden. I used it professionally for a few years around ~2012 and like many others moved off JVM and moved into typed [functional] languages.
Is the sudden buzz due to agentic coding? Does it rip through code faster with no type checking and fewer invalid syntax errors and reserved keywords to deal with? are we in for a sexp resurgence?
Personally I moved from typed functional languages to Clojurescript and then Clojure around 10 years ago
Most serious Clojure code bases I'm aware of invest heavily in their test suite so yes you can just add a skill to your AI that tells it the most effective way to use your test suite then send it to the races
Some of my colleagues let the agent interact with the REPL and they report faster performance because the agent is not paying the start up cost on every interaction, personally I've been lazy there its fast enough for me
As you've hinted at Clojure does have less bits that get in the way, everything is true except false and nil, the language does not have order precedence table the core language supports immutable and persistent data structures as default
Everything is an expression nothing is a mixture of operators and expressions
map, reduce, filter are built in and expected in normal code
Code you wrote 10 years ago in Clojure will likely still work today the ecosystem and language authors treat breaking code as taboo
Of all the languages I've used its the least headache inducing and the most freeing in terms of expressing my ideas
Also the defacto reverse debugger Flowstorm is a programming dream
Its a lovely language if you want to be content
The flip side of that is most users take it for granted and don't talk about it much
There are also a lot of commercial Clojure programmers who do not understand the language and as a result not that happy, they often didn't willing choose it, probably not ready for it, I think most Clojurians should have gone through a decade of noticing things in their other languages they didn't like before using it
Rich Hickey the creator of Clojure does famously influential videos on software but that doesn't mean your colleagues have watched them or care
Another feature that plays well with agentic coding is REPL driven development. I don't know why that approach hasn't caught on in more languages that could theoretically support it.
Because most languages don't have a full interactive REPL like for example Common Lisp has. The Python REPL for example is a joke compared to it. Clojure is very closely there, but not quite yet.
Been coding in lots of languages with agentic coding and it performs much better with typed languages since it basically corrects the agent if it does any hallucination errors. Especially during major refactorings. I have been dealing with large untyped python code bases and it sucks with AI since if it's not covered with tests it's such a teadious job to make sure it did not break anything. The stronger the type system the better it is. Also AI model is trained on code and the more popular the language is the better the AI will be at it. ClojureScript while nice is not a major language so I would assume AI would perform worse in it compared to javascript.
But in the end. Choose typed languages or dynamic languages with type hints if you are going for the AI route.
I’ve been using LLMs (the new Deepseek) on Clojure and it works well. The only major pain point is that it sucks at getting the last paren on. There are hooks that will fix that automatically, but I’ve been lazy.
I haven’t tried on anything completely blank, though. My projects have been sort of skeletons where I’m figuring out what I want it to look like, and it’s pretty good at imitating the patterns. Like I write functions to query a particular SQL table, and it can pick up how to use the SQL generation library from that.
It works pretty well. I also have it generating good docstrings though, which might help. Every function gets a “what does it do, why would you use it, what does it expect as args, what does it return” comment. If the function expects a map, the comments specify the keys it needs and so on.
You can also get typing (sort of) by using Malli or similar which does both runtime checking of schemas and serves as documentation of what the expected shape of the arg is. The LLM has been pretty good at falling back to looking at the schema if tests fail because of validation issues.
The logical conclusion is to use "a Haskell" typed language that will ensure every path is considered to guard against AI mistakes. OTOH, clojure repl, expressibility, immutability, and data-driven nature has its own advantages. Tacking on malli (runtime type checking) or spec (types/contracts) helps LLMs avoid type problems altogether or at least confront problems during testing.
Maybe that should be part of LLM benchmarking. If an LLM can handle untyped languages in the context window flawlessly, it would be a worthwhile accomplishment. I think For JS WebStorm loads a TS file for browser fundamentals and it helps drastically with this problem as well, sadly theres no similar concept for Python. Would be neat if someone implemented “Python Header Files” or something so you can provide type hints for these sort of projects.
So, best to just use <insert most popular language> for maximum results? And have the LLM just rehash the majority of what that language's code looks like? Because a lot of say Javascript code I have seen floating around on Github has been absolutely atrocious. That doesn't really give a good basis for LLMs.
I agree that stronger type systems might help. But a good swatch of unit tests should still accompany that code.
The Clojure code I have worked with usually had a damn good array of unit tests as its more of the "clojure" culture to do so.
Equating Clojure and Python just because they both dynamically typed is a very shallow comparison. The actual, practical experience is like a day and night. We have projects in Python, Clojure, Java, C# and Golang. Clojure is by far the least problematic to deal with. Even though they have many ugly and non-idiomatic, very old parts.
LLMs, matter of fact do work beautifully with Clojure, specifically because of the "true" REPL. Python doesn't have a comparable REPL - at best, Python's is an interactive shell.
When you give an LLM a closed loop system where it can evaluate code in a live REPL and immediately observe the results, it stops guessing and starts reasoning empirically.
With Clojurescript, you get a REPL connected to a browser - LLM can navigate any element, click buttons, have the entire page context to inspect and alter - all that without any compilation, without even saving and reloading any code anywhere. It seems you have zero idea how amazingly liberating the actual experience that is. And btw, it's the most token efficient language¹.
> ClojureScript is not a major language
a) There's plenty of Clojure code in the wild now and it's been there even before we started training LLMs.
b) The language is very small syntactically - it gives LLMs fewer ways to fantasize some weird constructs.
c) More popular languages have dozens of ways of doing similar things. Clojure's community is smaller and organized, there's less fragmentation - they don't have twenty different routing libraries, each with their own embedded DSL. You'd ask an LLM to get routing done in Python - every time it will give you a different answer, in Clojure - it would just pick something solid, community-approved, battle-tested and unambiguous.
I really wish people speculating about practical experiences in different languages had really used them before dumping their conclusions on HN. Because theory, papers and books are one thing - the practical, years-long venture into a language stack might be completely different experience. You can't be just like: "Haskell is great because it's pure and lazy and has types" and "Clojure is lame because it's dynamically typed" - the field experience would vary for a bunch of different reasons.
Every language has to be evaluated holistically and specifically for each situation. Just because we call them "general-purpose PLs", we shouldn't be generalizing them all the time.
Russian too. There is a subset of words which are referred to as "it", but for most words "he" or "she" are used regardless of whether these are living things or not. With loanwords we just decide by similarity to other words. Claude is definitely a "he" as the word is the same as a common male name.
This trips me up occasionally when I'm translating things into English. Once, when I referred to an indefinite gender player character in a gacha game as a "he" (because the word "player" is a "he"), quite a few people got mad! Even though in my head I was never trying to imply one way or the other.
For future reference, in this case you could use the singular "they" to refer to an ambiguously-gendered person or character. "<MC> drew their sword, for they would not tolerate such vile deeds."
> Cost remains an ever present challenge. Cursor’s larger rivals are willing to subsidize aggressively. According to a person familiar with the company’s internal analysis, Cursor estimated last year that a $200-per-month Claude Code subscription could use up to $2,000 in compute, suggesting significant subsidization by Anthropic. Today, that subsidization appears to be even more aggressive, with that $200 plan able to consume about $5,000 in compute, according to a different person who has seen analyses on the company’s compute spend patterns.
This is the relevant quote from the original article.
There are fast fashion attempts at this like adding elastic material to every fabric so they can get away with having fewer sizes and cuts thus less unsold inventory and availability issues. But everything has a tradeoff. In this case the elastic material degrades MUCH faster than cotton so you have to throw away your jeans quite a bit earlier compared to a quality 100% cotton denim which can last you a decade. This is very unfortunate as most of the fabric in that piece of clothing is perfectly fine and this is pure waste.
I'd noticed the near-universal adoption of stretch fabrics recently, and greatly dislike it. I hadn't considered that this is an inventory optimisation method, though that absolutely makes sense.
This is some next level nitpicking. It's like criticizing XCode or Idea config of someone, instead of their product (or more popularly whether their website hijacks the back button). But at least in this case the dev config is checked in and reproducible.
For years I thought I had a faulty touchscreen and started relying on dictation more and more. Seeing this video saved me from going insane. They must have crunched the numbers and decided that these choices benefit more people than not. BUT HOW!
Ok so it is not going closed source, they are just going to extend it as they need to drive Zed features. Totally understandable for an in-house UI framework, this is why you’d build one yourself anyway. I can imagine maintaining backwards compatibility, doing releases, writing documentation and growing a community around it is a considerable distraction from their product work.
Is the sudden buzz due to agentic coding? Does it rip through code faster with no type checking and fewer invalid syntax errors and reserved keywords to deal with? are we in for a sexp resurgence?