Expansion of standard library

The key point is that Rust comes out-of-the-box with a toolchain that makes adding a 3rd party crate to your project a completely hassle-free non-issue. That creates a complete paradigm shift for how we think about a “standard library”.

In many other language ecosystems, especially C++ (and I think Go to a lesser extent, until recently?), the reality is that the standard library is the only library for many if not most users, thus the bar for inclusion in the standard library is fundamentally not that far from “is this useful to people?” Any problem that’s “been solved already” becomes something we want to “standardize” just for the sake of allowing the rest of the C++ community to use it, because in practice 3rd party libraries are simply not worth the hassle.

In Rust, none of that applies. When all 3rd party code is just as easy to depend on as the standard library, there’s no longer any special availability advantage to being in the standard library. The idea that any “already solved problem” needs to be “standardized” simply evaporates into a non-problem, because once it’s on crates.io, then “everyone has it” in practice already. Moving it into std does not increase the availability any further.

So the “what should go in std?” question is completely different in Rust. Typical compelling arguments for putting things in the Rust standard library include “vocabulary types” (e.g. the whole Rust ecosystem needs to agree on a single str type just so everyone’s code can talk to each other), code that needs to interact with the compiler in some magical way, or tricky unsafe operations (because we trust std verification more than 3rd party crate verification, though even that could potentially change in the future), or platform abstractions that help keep a lot of Rust code portable-by-default (though that strategy didn’t scale as well as we hoped, so that might change too). All of these are pretty fuzzy and case-by-case criteria, not remotely official in any way. In fact, in the specific case of an HTTP server, there is an obvious vocabulary types problem, but the ecosystem ended up agreeing on a 3rd party crate for that and AFAIK no one’s ever asked for it to be moved into std.