HN is, at the time of writing, over 48 million posts over nearly two decades. Whatever you want to notice, you'll notice plenty of examples of. So, sure, I guess there has been plenty of "simping" over the years on HN. There has also been plenty of the opposite of it. As someone who reads the comments (particularly the most emotionally charged ones) every day, the sentiment towards prominent tech companies and leaders has been leaning decidedly negative on HN for several years.
Unless you're advocating for mass direct democracy, with public votes on everything under the sun, a certain level of delegation is inescapable at scale.
You say "career bureaucrats" as if they can't be fired or controlled, but that's obviously wrong (since they're being fired and/or controlled right now).
QED, they ARE still under public oversight. (1) Voters vote for (2) elected officials who oversee (3) agency bureaucrats.
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".
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.
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.
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.)
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.
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.
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.
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
That was in nov 2018. Two months later Tellman published his "Elements of Clojure". I don't remember the date when he retired from the community. And I don't remember him publicly saying anything about that drama, but I do know for a fact that he joined a team with a ton Scala. How do I know that? Not sure, he might have told someone I know. I might have heard that from him in person, honestly, I don't remember.
I can't speak for Zach, but in 2019 on The REPL podcast #23 (https://www.therepl.net/episodes/23/), at 00:41:01 and 00:45:31, he talks about being a bit unhappy with how the core team communicated about his arity-optimized vec/hash class proposal.
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.
> this is the first time, to my knowledge, that an AI tool has been restricted from assisting with something that's perceived as a threat to the AI company
You think so? I was under the impression that all the model providers have been trying to prevent use of their models to train competitor models for a while now.
reply