How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
I noticed borkdude posted this thread *and* he is listed as a contributor for this release.
For the longest time, I recall the opposition to async/await support being twofold:
1. adding support would require deep changes across the CLJS compiler (theller, creator of shadow-cljs, once tried and concluded this)
2. macros from libraries like Promesa provided similar convenience
There were some other arguments brought up at the time (e.g. just use core.async, expression-oriented languages aren't a good fit with async/await, etc.), but they were usually specific to one person rather than something you'd see repeated in forums.
In the Clojurians Slack, borkdude once stated he wasn't convinced it'd be impractical to add support. It seems that he eventually took the time and made it happen. Extremely thankful for that.
fun fact: clojurescript had support for asynchronous paradigm through core.async library (CSP style) long before async/await landed in javascript itself.
edit: i'm in no way trying to diminish the value of this release, just pointing out how cool it is that you can get new language features before they are available in the host language by just adding a library to your dependencies. clojure is awesome!
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?
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.
I wish an alternative to JS for the front end would catch on and be something more than obscure... I'd love to use something like clojurescript, but I struggle to imagine doing so for anything but a personal side project :/ Maybe this is easier to adopt if you're already a clojure shop for the backend?
Don't be afraid, it's great! I certainly wouldn't call it "obscure", I've been using it for 10 years now to compile a complex app into highly-optimized client-side code. And the community is very welcoming and mature.
Are you worried because it’s not a mainstream language and coworkers may not know it, or are you worried about the language itself getting abandoned or being bad or such?
I’ve not used it in production, but I’ve shipped a few side projects and stuff for family members in it. ClojureScripts React wrapper, Reagent, honestly makes more sense to me than React does. I used Hiccup to generate HTML, and your components are just functions within Hiccups DSL (which is really just lists) and it ends up looking incredibly clean. Static things look static, dynamic things are obviously so, and it felt much less magic than regular React.
The only things I found that felt bad were trying to use non-functional components I found on NPM. It’s not a deal breaker, but the code was ugly. Nothing I couldn’t fix with a wrapper, but some JS libraries are heinously ugly in cljs by default.
A big reason why react in clojure can make more sense than react itself is because clojure is much more declarative than JavaScript. There's been a lot of work done on the react end to fix that but the mismatch will always be there.
The type of code you're writing isn't special, it's the way people have written lots of clojure programs for over a decade.
> Static things look static, dynamic things are obviously so, and it felt much less magic than regular React.
Yes! The moment for me was when React introduced their notorious useEffect/useState hooks API. It immediately jumped out to me as the wrong API, by making static things dynamic. Reagent was really a breath of fresh air. Reagent was a really nice API, though it somewhat encouraged inefficient code.
I agree! I have kept an eye on Elm for many years, I think the simplicity and architecture is great, but the language itself never clicked for me.
Then I was made aware of Lustre[1], an Elm inspired web framework in Gleam. I have done two small projects in it now and I really enjoy working with both Lustre and Gleam.
> I struggle to imagine doing so for anything but a personal side project
Don't imagine. You have any bash scripts your team uses? Rewrite them in Babashka. Start with your own personal scripts first, get a knack for it, feel the benefits (it's not going to be universally better for every case). You have to be very confident about it personally, because people will come for your guidance later.
This is a good strategy for introducing unfamiliar things - pick something less important, rewrite it, let it sit there. If it becomes problematic - easy to revert. If people start liking it, you can add more, and so on.
That's how I sneaked F# in my .net shop years ago - I started writing less important tests in it.
Building UI in HTMX is such a breath of fresh air. I hope it kills the "React" style big complicated SPAs. Its so easy to develop in, its so fast to run, so fast to load.
Ten years ago we were writing ClojureScript for the frontend at work. We weren’t a Clojure shop at all. As my then manager said, picking ClojureScript was part of the hiring bar: people who weren’t interested in functional programming tended not to be good programmers and so we avoided hiring these people.
Check out Mint (https://mint-lang.com), it's s language where everything is built in: small to mid size projects can be built without any third party dependencies and JS interop is easy.
I haven't kept up with cljs in a long time but I remember it originally being pitched as just clojure on js--at least I think that's how Rich originally described it. My impression was it was just supposed to be, as much as possible, another runtime. This change seems to add in features that are exclusive to cljs and actually conflict with clojure itself as await is already a keyword in clojure.core. Have the two impls diverged over time, or was this feature specifically important enough to the users to overcome the differences?
You're still able to do so, as we've been able to in ClojureScript land for many years already, since ultimately they're just Promises! I don't think that's going away with this new function hints.
The beauty of Clojure/Lisp is that we have a nice macro system. Over the years, people created their own macros to simulate async/await. This is a powerful feature of Lisp, you don’t have to wait for an official release, you can just add that feature to the language yourself. Now we don’t have to use that custom macro anymore, which basically did the same thing.
Yeah, we went through this with core.async on a project a few years back. The channel model is genuinely elegant but the interop story with JS promises was always a bit painful — lots of manual wrapping. Native async/await should fix that. Ten years does feel like forever in JS-land though.
I'm not sure how I feel about this; wasn't part of the point of core.async to push all this stuff into channels? I'm not convinced that having a JS-style async keyword is an upgrade.
This is about using a JS feature without bringing in any additional dependencies like core.async. You don't have to use it and you can still use core.async. This was the most asked for feature in the recent ClojureScript survey.
The survey data point is what makes this hard to argue against. As far as I can tell, the core.async approach is theoretically cleaner — it doesn't conflate async with a specific execution model — but if practitioners consistently reach for a dependency just to do basic async IO, that friction is real and worth addressing.
We've shipped a couple ClojureScript apps and the interop story with promises was always the painful part. core.async is great until you're calling a JS library that returns a promise every other line. Native async/await just means less ceremony for the 90% case. Nobody's taking channels away.
Is that something people want to get rid of? Back when I did some clojurescript people were pretty proud of being able to have it used automatically. What's the plan to get the same benefits? Or is the argument that the benefits aren't significant 15ish years on?
I would say the community is pretty evenly split between people who hate it, and people who find it practical. I don't see many people really championing it or being proud of it these days.
Well, technically I think most of the community in indifferent. But from the discourse about the topic, I feel like I see pretty even splits.
I'm a very happy Google Closure Compiler user, especially with the "advanced optimizations" flag. It does a level of code elimination and variable renaming at a level that no other JavaScript tool even approaches. Excellent software.
I think it gets a bad rap because you need to write your code in a certain way to avoid the optimizations breaking things. But if you're a disciplined developer, you'll reap some large benefits.
Last i checked, it needed JVM (parts of the library are in Java). Given there are many JS minifiers and optimizers (tree shaking etc.) avaliable in JS itself in 2026, I do not know why we need this huge overhead.
I can finally use this little brain worm that has lived in my head for more than a decade now: IcedCoffeeScript has existed for ages https://maxtaco.github.io/coffee-script/ since well before ES got it.
Curious what this means for existing core.async codebases. Do you now have two async models living side by side, or does the new support somehow bridge channels to promises? Mixed async models in the same codebase tend to create subtle error propagation bugs — has anyone actually stress-tested that boundary?
For the longest time, I recall the opposition to async/await support being twofold:
1. adding support would require deep changes across the CLJS compiler (theller, creator of shadow-cljs, once tried and concluded this)
2. macros from libraries like Promesa provided similar convenience
There were some other arguments brought up at the time (e.g. just use core.async, expression-oriented languages aren't a good fit with async/await, etc.), but they were usually specific to one person rather than something you'd see repeated in forums.
In the Clojurians Slack, borkdude once stated he wasn't convinced it'd be impractical to add support. It seems that he eventually took the time and made it happen. Extremely thankful for that.