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

▲

jwr an hour ago | parent | next [-]

> 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 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 an hour ago | parent [-]

What is your opinion on farolero[0]?

[0]: https://github.com/IGJoshua/farolero

	▲	jwr 13 minutes ago \| parent [-]
		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 29 minutes ago | parent | prev | next [-]

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 6 minutes ago \| parent [-]
		Heh, I used to maintain manifold/aleph for a few years after Zach left the Clojure community.

▲

ares623 2 hours ago | parent | prev [-]

And here I thought I was too dumb to grok core.async all those years ago (ps I still am)