Agree. The documentation would make for a great talk. I'm going to spend a lot of time reading it, because the concepts it introduces are surely going to be useful no matter which tech i'll be using.
Futures-rs and Tokio were started by prolific Rust contributors so the community is gravitating towards making these crates the canonical async libraries for Rust. Since async primitives are so important and used in so many different ways, the maintainers are taking it slowly so that the community can provide as much feedback as possible. It may not be in the standard library but futures/Tokio will be the basis for most high level async in Rust so it's critical to get it right.
The Rust community also takes semver quite seriously. 0.1.0 can break API compatibility when it moves to 0.2.0, so prototypes that want to iterate on API stay pre-1.0 until they feel confident in their API. The Cargo ecosystem has shockingly few 2.x or 3.x versions.
By comparison to the long tail of the C library ecosystem (SONAME handling), and the package ecosystems of many other languages, most of which do not use sufficiently well-defined versioning schemes to allow expressing dependencies like "1.4 or any compatible version". In other languages, I've done the equivalent of "cargo update && cargo build" and encountered build errors due to API changes. In Cargo, I've found that exceptionally rare.
