I am not sure what is so "un-tempered" in the original message (assuming it is not technically incorrect) and what makes Rust so special that criticism must be "tempered with gratitude".
It's too vague. The claim is that async "still doesn't really work" but like, how so?
Sometimes you could make a claim like that about a feature and it's more or less accurate just as it stands. C++ 20 Modules were like that (still might be like that?) on most platforms, 'cos it turns out that's a lot of work for a compiler to implement and it's important to say you have the feature even if you know it doesn't work well. But even then, I'd rather see e.g. "C++ 20 Modules blow up if I try to A, or B, or C... or Z" it's just that I can understand if your list is a page long "doesn't really work" seems more concise than listing everything.
There are clearly people who are frustrated by aspects of Rust's async. Some of those frustrations are fixable, some are consequences of a principle decision that's unlikely to be revisited, and who knows if you won't say what frustrated you
Suppose I said Go's generics "don't really work". Do I mean that they aren't monomorphised in the way I hoped? That the syntax is too untidy for me? That the Go libraries aren't yet making them ergonomic? That I found a compiler bug? No way to know.
Well, I have several production services. They are written in async rust. If they didn't work, or worked poorly, or even worked sorta good - you'd know it, the outages would be front page news in the tech press and maybe even on "the news".
I didn't have to do anything special to make them work well, just out of the box tokio and a small bit of learning how to do stuff that's weird to do in most any language (e.g. netlink, bpf maps and so on).
I don't know what the definition of "doesn't really work" is, but it seems technically incorrect given how my services run for months at a time between restarts (which I consider a symptom of working).
Rust isn't special; what I said applies to any open-source project. But people have been pretty harsh about async in Rust lately, and IMO the message I was replying to makes the problem sound worse than it is.
Sometimes you could make a claim like that about a feature and it's more or less accurate just as it stands. C++ 20 Modules were like that (still might be like that?) on most platforms, 'cos it turns out that's a lot of work for a compiler to implement and it's important to say you have the feature even if you know it doesn't work well. But even then, I'd rather see e.g. "C++ 20 Modules blow up if I try to A, or B, or C... or Z" it's just that I can understand if your list is a page long "doesn't really work" seems more concise than listing everything.
There are clearly people who are frustrated by aspects of Rust's async. Some of those frustrations are fixable, some are consequences of a principle decision that's unlikely to be revisited, and who knows if you won't say what frustrated you
Suppose I said Go's generics "don't really work". Do I mean that they aren't monomorphised in the way I hoped? That the syntax is too untidy for me? That the Go libraries aren't yet making them ergonomic? That I found a compiler bug? No way to know.