ClojureScript Gets Async/Await(clojurescript.org) |
ClojureScript Gets Async/Await(clojurescript.org) |
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.
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!
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":
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.
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
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".
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 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.
(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.)
I loved ztellman’s “everything must flow” talk on the topic.
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?
Congratulations on the release :-)
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
https://clojurescript.org/guides/promise-interop#using-promi...
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 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.
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
Live image editing is just pure bliss.
But in the end. Choose typed languages or dynamic languages with type hints if you are going for the AI route.
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.
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.
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.
___
¹ https://martinalderson.com/posts/which-programming-languages...
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.
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.
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.
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.
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.
I came to the conclusion that the best frontend is no frontend.
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.
It’s a breath of fresh air that practically every DSL takes either lists or maps so I can use very similar patterns to build their input rather than “every API wants me to method chain their custom types so every API needs its own special helpers library for common patterns”.
I never realized how much I hate classes until Clojure.
Have you tried typed Clojure? Curious about opinions on that vs having Malli do runtime validation. I tried it when I was a total noob and got overwhelmed. I feel like I have just enough context now to try again, and not sure if it’s nice or the overhead is so high it’s a boondoggle
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.
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.
AFAIK Zach was just offered well-paying job that was mostly about dealing with Scala, it wasn't about "how the language should evolve"...
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
He then talks about Aphyr's and Chas Emerick's similar experiences, and laments how in the earliest days, it was still possible to contribute, and how when core development closed off, it was never articulated up front until "Open Source Is Not About You", which is its own can of worms.
Overall, it's a good and nuanced discussion, but it's obvious he wasn't in unreserved love with the language, so I'm not surprised he left.
Yeah, no, I'm not saying Zach wasn't unhappy with the whole core team vs Emerick drama, none of us were. I kinda get it, but also, I don't get it like at all. There are so many tiny details I don't know anything about, but I also feel it was somewhat personal, not really socio-technological (so to speak). Otherwise, we would've maybe seen a big split and a Clojure fork. I see the similar tension (for years) now in Emacs and Org-mode camps. Contributing to core Emacs has similar pain points - specific workflows (no PRs - patches discussed in the mailing list, tone of dismissal toward community-submitted fixes, etc.), but I don't see any big contributors going like: "fuck it, I'm tired of this BS, I'm gonna go contribute to Neovim instead..."
It is really sad that Chas decided to leave slamming the door, makes it almost impossible to imagine him returning and contributing to let's say to Jank, which afaik has none of the hurdles he complained about.