3 ms·

While I can see why zero-cost abstractions are important in Rust, I was wondering how much simpler Rust async could have been if zero-cost had not been a hard r

While I can see why zero-cost abstractions are important in Rust, I was wondering how much simpler Rust async could have been if zero-cost had not been a hard requirement. The way I see it, Rust async is most useful for IO-bound applications, which can afford some non-zero abstraction CPU cost.

estebank 4y ago
If zero-cost wasn't an aim then it would indeed be much easier. For example, async fn in traits isn't (yet) in the language. The type system level changes to make them possible is being actively worked on (it is high priority!), but if we didn't care about "you can't write more efficient code by hand", then we would have provided that feature with the semantics of the async-trait crate[1], which provides a macro that turns `async fn foo() -> i32 { 42 }` into `fn foo() -> BoxFuture<Output = i32> { Box::new(async { 42 }) }`. Going down that route would have "silenced" that criticism, at the cost of locking us to subpar behavior at least until the next edition. The approach of waiting until things are baked well enough to land in stable is frustrating as a user today, but I believe has a better chance of standing up to scrutiny long term. In the meantime, the community is able to "plug" those failings, at the cost of worse dev UX due to not being builtin. [1]: https://crates.io/crates/async-trait https://crates.io/crates/async-trait