Our goal is to bring async/await onto a path to stabilization and to provide documentation for asynchronous programming:
- Futures 0.3 and async/await should be vetted, well-documented, well-integrated, future-proof, and on a clear path to stabilization.
- The futures-rs blog aims to give regular updates on the latest changes to
awaitand the futures library.
- The Asynchronous Programming in Rust book **should have a complete draft, covering async/await, core futures concepts, Tokio, and enough of the ecosystem to give good examples and guidance. It should also explicitly talk about the stabilization situation, including how to bridge between stable 0.1 and unstable 0.3 worlds.
|Discord handle||Github handle|
Futures 0.3 and async/await
This section explains in further detail what is meant by the above short description for futures 0.3 and
futures 0.3 must be used in existing production deployments of Tokio and other asynchronous frameworks. Any non-essential runtime structure decisions imposed by
task::Context (e.g. the structure of
LocalWaker) must be thoroughly benchmarked against alternatives so that no optimization opportunities are being lost by stabilizing the interface.
The capabilities of
await need to be validated by porting existing 0.1 applications and libraries (like
hyper) to make use of it.
futures 0.3 and the
std::task module must be well-documented and comprehensible to a beginner without significant external resources. The “Asynchronous Programming in Rust” book must be ready for public consumption and must have gone through review by multiple Rust users new to asynchronous programming.
await must be usable with existing
futures 0.1-based libraries, and multiple existing 0.1 libraries (including
hyper) must have successfully ported to use
futures 0.3 under the hood without any loss of performance.
futures 0.1-based applications must be able to gradually adopt
futures 0.3 without significant interruption to their development cycle.
await syntax should be vetted for consistency with existing and planned language features. In particular consistency with the planned generator function and async generator function syntaxes is desired. A plan for how these feature could look like with consistent syntax needs to be established before
await can be stabilized.
Clear Path Towards Stabilization
All of the remaining technical blockers towards
await stabilization must be resolved:
Consensus must be achieved among stakeholders (major library authors, production users, and other significantly interested parties) that the APIs in
std::future are high-quality, leave no performance on the table, and provide a high-quality
await-style developer experience.
Major stakeholders must see a path to using the
await programming style in their existing applications. Blockers to adoption (such as
async fn in traits, named existentials, or other language or library features) must have clear plans and goal timelines for resolution.