Setting aside the issue of delays (I agree with that; this is why I started blogging about async Rust again even though I am no longer part of the project), Rust cannot solve the problem except with async because of its prior commitment to "the C runtime." I've written about this in other posts, but this comment from PhantomZorba on lobste.rs describes the situation succinctly:
Async style language features are a compromise between your execution model being natively compatible with the 1:1 C ABI, C standard library, and C runtime and a M:N execution model. C++ async suffers from the same issues, except it’s not as strict in terms of lifetime safety (not a good thing). The cost for the native compatibility with the C/system runtime is the “function coloring” problem.
Go, Haskell, and I assume Erlang make the other compromise. They eschew the C ABI and runtime completely and implement their own standard library. All code ends up being color-clean. The cost is that integrating with code outside their ecosystem is complex and slow.
Comments
Setting aside the issue of delays (I agree with that; this is why I started blogging about async Rust again even though I am no longer part of the project), Rust cannot solve the problem except with async because of its prior commitment to "the C runtime." I've written about this in other posts, but this comment from PhantomZorba on lobste.rs describes the situation succinctly:
https://lobste.rs/s/jkct2m/avoid_async_rust#c_0dqqlv
100%! I'm so glad someone sees it for how it is.