6 ms·

ClojureScript Gets Async/Await

279 points by Borkdude 5mo ago

midnight_eclair 5mo ago
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!
- KingMob 5mo ago
  True, but there are many reasons to avoid core.async, especially in 2026. It balloons up the Js artifact, has no inherent error model, and transforms into state machine code that's hard to read/debug if something goes wrong. Plus, the `go` macro encourages overly-large functions, because it can't transform code outside its own sexpr. As one Cognitect put it, "core.async is beautiful nonsense".
  - ares623 5mo ago
    And here I thought I was too dumb to grok core.async all those years ago (ps I still am)
  - jwr 5mo ago
    > has no inherent error model I'll pitch in here, as I've been doing a lot of thinking about this issue and ended up writing my own (tiny) tools for handling anomalies, modeled on the very well thought-out https://github.com/cognitect-labs/anomalies https://github.com/cognitect-labs/anomalies categorization. This is actually a much wider problem and not specific to core.async. Handling anomalies is difficult. It used to be that you would have exceptions and errors which would be thrown, unwinding the stack. This pattern no longer works in asynchronous code, or code that needs to pass anomalies between the server and the client. In practical applications, an anomaly might need to be returned from a function, passed through a `core.async` channel, then thrown, unwinding the stack on the server side, then caught and passed to the client side over a WebSocket, and then displayed to the user there. Solving this well is not easy. I think my toolkit, iterated and improved over the years, is close to what I need. But I'm pretty sure it wouldn't handle all the real-world use cases yet. But again, this is not specific to core.async in any way.
    - alhazrod 5mo ago
      What is your opinion on farolero[0]? [0]: https://github.com/IGJoshua/farolero https://github.com/IGJoshua/farolero
      - jwr 5mo ago
        At a first glance, it does much more than what I would want to. My status toolkit just extends the Cognitect anomalies to be statuses, adding ::failed (parameters correct, but could not perform request), ::ok, ::accepted and ::in-progress. It also adds a bunch of utility functions like status/?! (throws the parameter if it's anomaly, returns the parameter otherwise) and macros like status/-?> (threads if an expression is not an anomaly). That's it. I deliberately avoid trying to do too much here.
  - stingraycharles 5mo ago
    For me it also lacks observability. It has been a few years since I last used Clojure, but I found manifold to be a much better fit for actual production code that you want to optimize. I loved ztellman’s “everything must flow” talk on the topic.
    - KingMob 5mo ago
      Heh, I used to maintain manifold/aleph for a few years after Zach left the Clojure community.
      - stingraycharles 5mo ago
        That means we have had various exchanges in the past, but I’m operating under a different username here. I’ve had several PRs accepted into there, I think manifold got a lot of things right, if only it weren’t for Zach leaving the community. Unfortunately I left the community for similar reasons, I have a different vision of how the language should evolve than the people in charge, but wasn’t as vocal about it. I suspect there are more people like me. It’s fine, like Rich Hickey said, it’s his project and we have no right to expect anything. I am forever glad for what Clojure taught me, it made me a much better developer.
        iLemming 5mo ago
        > Unfortunately I left the community for similar reasons AFAIK Zach was just offered well-paying job that was mostly about dealing with Scala, it wasn't about "how the language should evolve"...
        stingraycharles 5mo ago
        Zach wanted to introduce a community-driven steering community, make the language easier for beginners to adopt, and standardize library choices. This did not align with Cognitect’s centralized stewardship. This was around the time that there was some quite some commotion in the community around this, with Rich posting his infamous “Open source is not about you” conclusive post, which was in direct response to @cemerick’s Twitter post: https://x.com/cemerick/status/1067111260611850240 https://x.com/cemerick/status/1067111260611850240
  - eduction 5mo ago
    All async systems have pitfalls, I'd say core.async's are pretty minor compared to most other systems. You're right that `go` can encourage bloated functions and it would be better if it, for example, handled exception propagation (I would guess every serious core.async user has written their own go-but-with-exception-handing macro, it's not hard but it is unfortunate duplication of effort). (I've never had to think about the state machine code when debugging and I've done a lot of core async debugging. That part really does seem to just work.)
    - KingMob 5mo ago
      To be more clear, I didn't mean debugging the generated state machine itself. What I meant was, the use of the go state machine renders certain debugging techniques useless. E.g., stacktraces are less helpful, and js-debugger is pointless, since you can't guarantee the (js-debugger) will get grouped with the state you're trying to debug. Frequently print/tap is sufficient, but core.async/go narrows your options.
- TacticalCoder 5mo ago
  > fun fact: clojurescript had support for asynchronous paradigm through core.async library (CSP style) long before async/await landed in javascript itself. Definitely. I was heavily using it and it worked: a few quirks but we did have async/await since more than a decade. I think I discovered it after watching a talk by David Nolen. Since then I moved to minimal JavaScript on the front-end: SSE is one-way and that is beautiful. I'm glad to see many devs, from a great many different languages, now getting interested in SSE. Here's a great, recent, talk by David Nolen called "A ClojureScript Survival Kit": https://youtu.be/BeE00vGC36E https://youtu.be/BeE00vGC36E I cannot thanks David "Swannodette" Nolen enough for all the work he did on ClojureScript (and core.async) since its inception. And what's amazing in this talk is that he's actually excited at the idea that we may do away with ClojureScript and use pure Clojure (on the server-side) and server-side events, with just a tiny of JavaScript. The real demo starts around 26:30. He shows a Webapp running on the client and how much resources it's using, then he shows the exact same Webapp running on the server and pushed one-way to the client using SSE. It is wild: resources usage drops to near zero. YMMV but I find it easier to reason about my webapps and manage state now that I'm using a minimal DOM morphing lib: I used to have two REPLs (one for Clojure, one for ClojureScript) and lots of back-and-forth traffic and hard-to-track / reproduce state. Now everything is definitely snappier and way easier to reproduce. I'm not saying SSE is going to work in every case though: YMMV. But in any case the video or at the very least the demo starting @ 26:30 is very much worth watching.
  - midnight_eclair 5mo ago
    thanks for the link, i was just recently trying to find that talk! re server-side rendered fragments - htmx is extremely easy to integrate with your clojure(script) projects, i found it to be quite pleasant paradigm, but i have no skin in the game so take it with grain of salt xD
zerr 5mo ago
For the moment thought the article was about CoffeeScript... But it already supports async/await :)
- rpastuszak 5mo ago
  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/ https://maxtaco.github.io/coffee-script/ since well before ES got it.
timwis 5mo ago
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?
- oDot 5mo ago
  You should try Gleam. I'm using it in production to great delight: https://blisswriter.app/ https://blisswriter.app/ https://blog.nestful.app/p/how-we-dropped-vue-for-gleam-and https://blog.nestful.app/p/how-we-dropped-vue-for-gleam-and
  - eliasson 5mo ago
    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. [1] https://github.com/lustre-labs/lustre https://github.com/lustre-labs/lustre
- jwr 5mo ago
  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.
- ezst 5mo ago
  https://www.scala-js.org/ https://www.scala-js.org/ is quite phenomenal.
- xmcqdpt2 5mo ago
  After reading https://hypermedia.systems/ https://hypermedia.systems/ I came to the conclusion that the best frontend is no frontend.
  - 5mo ago
nbardy 5mo ago
Seems like wrapping async await functions with CSP was a better way to handle this . Clojure already had a nicer pattern for this
- midnight_eclair 5mo ago
  this release is about exposing the host language primitives to clojurescript core.async isn't going anywhere, if async/await works better than promise based implementation, core.async will get an update in it's .cljs parts
- embedding-shape 5mo ago
  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. https://clojurescript.org/guides/promise-interop#using-promises-with-core-async https://clojurescript.org/guides/promise-interop#using-promi...
slifin 5mo ago
This is important for JavaScript interop without having to include additional libraries very cool and was missing for a long time Congratulations on the release :-)
rockyj 5mo ago
Nice! Now also get rid of the elephant in the room - "Google Closure Compiler" and then we can really celebrate.
- Jach 5mo ago
  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?
  - hrrld 5mo ago
    No, you're right, we don't want to get rid of it; it's great.
  - barrell 5mo ago
    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.
  - rockyj 5mo ago
    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.
  - adrianh 5mo ago
    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.
boczez 5mo ago
Massive, cheers dude and congrats on the release. I’d say it’s such a good time to get into Clojure/Script but, well … it has been for a while!
osener 5mo ago
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?
- Zak 5mo ago
  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.
  - rootnod3 5mo ago
    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. Live image editing is just pure bliss.
- perarneng 5mo ago
  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.
  - giancarlostoro 5mo ago
    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.
seanclayton 5mo ago
I remember a decade ago when JavaScript got Async/Await. 10 years is quite a long time.
- ertucetin 5mo ago
  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.
- worthless-trash 5mo ago
  Clojurescript already had it, just didnt use native async.
chr15m 5mo ago
Epic win for cljs, congratulations!
moomin 5mo ago
I'm guessing there's no likelihood of a regular Clojure equivalent of this?
koito17 5mo ago
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.
- lilactown 5mo ago
  I believe Borkdude showed it was possible by first implementing async/await in Squint, his alternative* implementation of ClojureScript, and then took those learnings to the core CLJS compiler.
arikrahman 5mo ago
This is huge. I haven't been this excited about the Clojure ecosystem since Jank got announce (which is pretty recently to be fair)
tombert 5mo ago
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.
- Borkdude 5mo ago
  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.
  - tombert 5mo ago
    Fair, I guess I import core.async into every project implicitly so I forgot that it's a separate dep.
jhhh 5mo ago
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?

279 points by Borkdude 5mo ago

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!

KingMob 5mo ago
True, but there are many reasons to avoid core.async, especially in 2026. It balloons up the Js artifact, has no inherent error model, and transforms into state machine code that's hard to read/debug if something goes wrong. Plus, the `go` macro encourages overly-large functions, because it can't transform code outside its own sexpr. As one Cognitect put it, "core.async is beautiful nonsense".
- ares623 5mo ago
  And here I thought I was too dumb to grok core.async all those years ago (ps I still am)
- jwr 5mo ago
  > has no inherent error model I'll pitch in here, as I've been doing a lot of thinking about this issue and ended up writing my own (tiny) tools for handling anomalies, modeled on the very well thought-out https://github.com/cognitect-labs/anomalies https://github.com/cognitect-labs/anomalies categorization. This is actually a much wider problem and not specific to core.async. Handling anomalies is difficult. It used to be that you would have exceptions and errors which would be thrown, unwinding the stack. This pattern no longer works in asynchronous code, or code that needs to pass anomalies between the server and the client. In practical applications, an anomaly might need to be returned from a function, passed through a `core.async` channel, then thrown, unwinding the stack on the server side, then caught and passed to the client side over a WebSocket, and then displayed to the user there. Solving this well is not easy. I think my toolkit, iterated and improved over the years, is close to what I need. But I'm pretty sure it wouldn't handle all the real-world use cases yet. But again, this is not specific to core.async in any way.
  - alhazrod 5mo ago
    What is your opinion on farolero[0]? [0]: https://github.com/IGJoshua/farolero https://github.com/IGJoshua/farolero
    - jwr 5mo ago
      At a first glance, it does much more than what I would want to. My status toolkit just extends the Cognitect anomalies to be statuses, adding ::failed (parameters correct, but could not perform request), ::ok, ::accepted and ::in-progress. It also adds a bunch of utility functions like status/?! (throws the parameter if it's anomaly, returns the parameter otherwise) and macros like status/-?> (threads if an expression is not an anomaly). That's it. I deliberately avoid trying to do too much here.
- stingraycharles 5mo ago
  For me it also lacks observability. It has been a few years since I last used Clojure, but I found manifold to be a much better fit for actual production code that you want to optimize. I loved ztellman’s “everything must flow” talk on the topic.
  - KingMob 5mo ago
    Heh, I used to maintain manifold/aleph for a few years after Zach left the Clojure community.
    - stingraycharles 5mo ago
      That means we have had various exchanges in the past, but I’m operating under a different username here. I’ve had several PRs accepted into there, I think manifold got a lot of things right, if only it weren’t for Zach leaving the community. Unfortunately I left the community for similar reasons, I have a different vision of how the language should evolve than the people in charge, but wasn’t as vocal about it. I suspect there are more people like me. It’s fine, like Rich Hickey said, it’s his project and we have no right to expect anything. I am forever glad for what Clojure taught me, it made me a much better developer.
      - iLemming 5mo ago
        > Unfortunately I left the community for similar reasons AFAIK Zach was just offered well-paying job that was mostly about dealing with Scala, it wasn't about "how the language should evolve"...
        stingraycharles 5mo ago
        Zach wanted to introduce a community-driven steering community, make the language easier for beginners to adopt, and standardize library choices. This did not align with Cognitect’s centralized stewardship. This was around the time that there was some quite some commotion in the community around this, with Rich posting his infamous “Open source is not about you” conclusive post, which was in direct response to @cemerick’s Twitter post: https://x.com/cemerick/status/1067111260611850240 https://x.com/cemerick/status/1067111260611850240
- eduction 5mo ago
  All async systems have pitfalls, I'd say core.async's are pretty minor compared to most other systems. You're right that `go` can encourage bloated functions and it would be better if it, for example, handled exception propagation (I would guess every serious core.async user has written their own go-but-with-exception-handing macro, it's not hard but it is unfortunate duplication of effort). (I've never had to think about the state machine code when debugging and I've done a lot of core async debugging. That part really does seem to just work.)
  - KingMob 5mo ago
    To be more clear, I didn't mean debugging the generated state machine itself. What I meant was, the use of the go state machine renders certain debugging techniques useless. E.g., stacktraces are less helpful, and js-debugger is pointless, since you can't guarantee the (js-debugger) will get grouped with the state you're trying to debug. Frequently print/tap is sufficient, but core.async/go narrows your options.
TacticalCoder 5mo ago
> fun fact: clojurescript had support for asynchronous paradigm through core.async library (CSP style) long before async/await landed in javascript itself. Definitely. I was heavily using it and it worked: a few quirks but we did have async/await since more than a decade. I think I discovered it after watching a talk by David Nolen. Since then I moved to minimal JavaScript on the front-end: SSE is one-way and that is beautiful. I'm glad to see many devs, from a great many different languages, now getting interested in SSE. Here's a great, recent, talk by David Nolen called "A ClojureScript Survival Kit": https://youtu.be/BeE00vGC36E https://youtu.be/BeE00vGC36E I cannot thanks David "Swannodette" Nolen enough for all the work he did on ClojureScript (and core.async) since its inception. And what's amazing in this talk is that he's actually excited at the idea that we may do away with ClojureScript and use pure Clojure (on the server-side) and server-side events, with just a tiny of JavaScript. The real demo starts around 26:30. He shows a Webapp running on the client and how much resources it's using, then he shows the exact same Webapp running on the server and pushed one-way to the client using SSE. It is wild: resources usage drops to near zero. YMMV but I find it easier to reason about my webapps and manage state now that I'm using a minimal DOM morphing lib: I used to have two REPLs (one for Clojure, one for ClojureScript) and lots of back-and-forth traffic and hard-to-track / reproduce state. Now everything is definitely snappier and way easier to reproduce. I'm not saying SSE is going to work in every case though: YMMV. But in any case the video or at the very least the demo starting @ 26:30 is very much worth watching.
- midnight_eclair 5mo ago
  thanks for the link, i was just recently trying to find that talk! re server-side rendered fragments - htmx is extremely easy to integrate with your clojure(script) projects, i found it to be quite pleasant paradigm, but i have no skin in the game so take it with grain of salt xD

zerr 5mo ago

For the moment thought the article was about CoffeeScript... But it already supports async/await :)

rpastuszak 5mo ago
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/ https://maxtaco.github.io/coffee-script/ since well before ES got it.

timwis 5mo ago

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?

oDot 5mo ago
You should try Gleam. I'm using it in production to great delight: https://blisswriter.app/ https://blisswriter.app/ https://blog.nestful.app/p/how-we-dropped-vue-for-gleam-and https://blog.nestful.app/p/how-we-dropped-vue-for-gleam-and
- eliasson 5mo ago
  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. [1] https://github.com/lustre-labs/lustre https://github.com/lustre-labs/lustre
jwr 5mo ago
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.
ezst 5mo ago
https://www.scala-js.org/ https://www.scala-js.org/ is quite phenomenal.
xmcqdpt2 5mo ago
After reading https://hypermedia.systems/ https://hypermedia.systems/ I came to the conclusion that the best frontend is no frontend.
- 5mo ago

nbardy 5mo ago

Seems like wrapping async await functions with CSP was a better way to handle this . Clojure already had a nicer pattern for this

midnight_eclair 5mo ago
this release is about exposing the host language primitives to clojurescript core.async isn't going anywhere, if async/await works better than promise based implementation, core.async will get an update in it's .cljs parts
embedding-shape 5mo ago
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. https://clojurescript.org/guides/promise-interop#using-promises-with-core-async https://clojurescript.org/guides/promise-interop#using-promi...

slifin 5mo ago

This is important for JavaScript interop without having to include additional libraries very cool and was missing for a long time Congratulations on the release :-)

rockyj 5mo ago

Nice! Now also get rid of the elephant in the room - "Google Closure Compiler" and then we can really celebrate.

Jach 5mo ago
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?
- hrrld 5mo ago
  No, you're right, we don't want to get rid of it; it's great.
- barrell 5mo ago
  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.
- rockyj 5mo ago
  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.
- adrianh 5mo ago
  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.

boczez 5mo ago

Massive, cheers dude and congrats on the release. I’d say it’s such a good time to get into Clojure/Script but, well … it has been for a while!

osener 5mo ago

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?

Zak 5mo ago
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.
- rootnod3 5mo ago
  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. Live image editing is just pure bliss.
perarneng 5mo ago
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.
- giancarlostoro 5mo ago
  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.

seanclayton 5mo ago

I remember a decade ago when JavaScript got Async/Await. 10 years is quite a long time.

ertucetin 5mo ago
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.
worthless-trash 5mo ago
Clojurescript already had it, just didnt use native async.

chr15m 5mo ago

Epic win for cljs, congratulations!

moomin 5mo ago

I'm guessing there's no likelihood of a regular Clojure equivalent of this?

koito17 5mo ago

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.

lilactown 5mo ago
I believe Borkdude showed it was possible by first implementing async/await in Squint, his alternative* implementation of ClojureScript, and then took those learnings to the core CLJS compiler.

arikrahman 5mo ago

This is huge. I haven't been this excited about the Clojure ecosystem since Jank got announce (which is pretty recently to be fair)

tombert 5mo ago

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.

Borkdude 5mo ago
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.
- tombert 5mo ago
  Fair, I guess I import core.async into every project implicitly so I forgot that it's a separate dep.

jhhh 5mo ago

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?