I believe the rationale goes like this: Rust doesn't have a runtime, and the designers prefer to to keep it that way. But, there was also a desire for native-fe

I believe the rationale goes like this: Rust doesn't have a runtime, and the designers prefer to to keep it that way. But, there was also a desire for native-feeling async programming in Rust. In order to reconcile these seemingly opposing stances, an abstract Future trait was added to the standard library with no implementation, along with async and await keywords to operate with it. This way, an async runtime could live outside of the standard library, but developers would still get to use nice built-in keywords. It's worth noting that despite there not being an async runtime shipped with Rust, the designers have taken an opinionated stance on the use of "stackless" coroutines. The await keyword is only allowed inside of a function/block declared async, and suchs blocks always get rewritten by the compiler. The end result is truly impressive though. Async Rust is more efficient CPU-wise and memory-wise than anything I've ever heard of. So while async Rust might be difficult to understand and use at times, it's this way in the name of efficiency (good description of Rust in general :)). I did some benching to compare hand written poll loop code to async code here: https://github.com/jkarneges/rust-async-bench https://github.com/jkarneges/rust-async-bench