ClojureScript Gets Async/Await

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

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 loved ztellman’s “everything must flow” talk on the topic.

(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.)

Live image editing is just pure bliss.

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.

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 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.

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.

[1] https://github.com/lustre-labs/lustre

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.

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.