Here's the proposal: https://internals.rust-lang.org/t/explicit-future-construction-implicit-await/7344 https://internals.rust-lang.org/t/explicit-future-constr

Here's the proposal: https://internals.rust-lang.org/t/explicit-future-construction-implicit-await/7344 https://internals.rust-lang.org/t/explicit-future-constructi... One of the goals behind it was to align async control flow with sync/thread-based control flow, to make it more intuitively obvious when things would run concurrently and when they would not. That is, calling a function, even if async, would immediately run it to completion, while wrapping it up in a closure or async block that gets spawned would run it concurrently. This is especially relevant to Rust, which departs from other implementations of async/await in that merely constructing a future is insufficient to start it running, which is why you need that `join3` call to explicitly introduce concurrency. Under the "implicit await" proposal, your first example would look like this: async fn foo() { let result = blocking_req(); // await immediately let future = async { blocking_req() }; // think of async{} like a lambda function // can do more complex stuff with the future, like: // future.await() // Future::join(future, other_future) // tokio::spawn(future) } The thread-based equivalent looks very similar: fn foo() { let result = blocking_req(); // block the current thread immediately let closure = || { blocking_req() }; // don't run this yet // can do more complex stuff with the closure, like: // closure() // rayon::join(closure, other_closure) // thread::spawn(closure) }