It might be worth making those "official" then, if it's not worth having everyone reimplementing them? If they're the standard in all but name, to the point where official material is referring to them as the preferred way to do things, I don't see why they should remain as third-party dependencies.
In other for their APIs to evolve independently of the compiler's release cycle.
In Python it is often said that stdlib is where modules go to die, and dependency management in Rust is a particularly different experience to most other languages. A good example of why keeping the standard library lean can be a good idea in the long term would be datetime handling in Java: https://stackoverflow.com/questions/12032051/differences-bet...
Re:Rust Cookbook
by steveklabnik on Monday March 18, 2019 @11:20AM
(#19421783)
Some of these are produced by the rust project itself, but not all.
We can’t just take control of a project just because it’s popular, that’s not really how open source works.
There are some very well solved problems and I don’t think Rust should hide the fact that you can also rely on those. The idea of a cookbook is to solve common problems — and sometimes the easier way to do this is to use an battletested external dependency.