Traits now support async fn and -> impl Trait (with some limitations), the compiler got faster, version = in Cargo.toml is now optional, and many small functions have been stabilized!
Traits now support async fn and -> impl Trait (with some limitations), the compiler got faster, version = in Cargo.toml is now optional, and many small functions have been stabilized!
This conclusion is a very weak one.
The only argument the article successfully makes is that using the raw async/await mechanisms of the Rust language leads to situations where it’s tricky to figure out how to structure your code, and that the raw async mechanisms of some other languages don’t have that friction.
But why would we only consider the strengths of the pure out-of-the-box Rust language and forget that it has an enormous robust ecosystem of crates? For any given use case there will be suitable frameworks that make async Rust programming both natural and performant. Or if such a framework doesn’t exist it is possible to develop one on top of the async mechanisms of the raw language because those mechanisms are so unopionated by design.
My colleagues struggle with async Rust as-is. I did too for quite a while. But that’s why I’m developing two different async Rust frameworks for two different software architecture paradigms (one that fits nicely into an ECS and one that fits nicely into a deterministic scheduled worker pool) each of which we have different use cases for. If the Rust async design was more opinionated and imposing (which is what this article is recommending) then I likely wouldn’t be able to produce frameworks that are as effective for each of these use cases… one or the other would have suffered, likely both.