3 ms·
I agree and I'm not advocating for Rust's std to gain things like http clients or template engines. But some parts of the ecosystem end up in a lot of projects
by the_duke 7y ago
I agree and I'm not advocating for Rust's std to gain things like http clients or template engines.
But some parts of the ecosystem end up in a lot of projects. Conservatively extending std would be good for the language, IMO. To set a standard, reduce compile times, and ease the burden for companies that have hard review requirements for each dependency.
Some things I'd like to see in std in a few years:
* `serde`
* `rand`
* `log`, but probably without a backend, or a simple default
* a subset of `chrono`
* some parts of `rayon`
- Sean1708 7y agoWhat about a set of "blessed" crates (that can only depend on other "blessed" crates) that are maintained by the language developers? Seems like the best of both worlds to me.
- eridius 7y agoI think we could strike a balance. Don't put this stuff in the standard library, but have a category for crates that are officially blessed (or even maintained by) the core team, such that if you trust the Rust stdlib then you should be comfortable trusting these crates. Then provide binary distributions for the built crates for all tier 1 platforms at least (ideally for any platform where a binary distribution of the stdlib is available) and teach cargo how to download those. This way we maintain the ability to version these crates and have breaking changes, but without the overhead of having to recompile these crates.