3 ms·
That is a serious amount of documentation for a 0.1 release.
by jononor 10y ago
That is a serious amount of documentation for a 0.1 release.
- bsaul 10y agoAgree. 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.
- wyldfire 10y agoThe rust community suffers here from humility and a modest default (`cargo new` puts you at 0.1.0 by default).
- akiselev 10y agoFutures-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.
- JoshTriplett 10y agoThe 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.
- kzrdude 10y agoWhen you say this, what experience are you comparing to? Any particular package ecosystems, or a general rule? Thanks
- JoshTriplett 10y agoBy 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.