I disagree quite strongly. A bad stdlib API can be deprecated; a bad crate bitrots. You won't see the situation so clearly at first, but after a few years you will find that an increasing number of useful crates no longer compile without intervention because direct or transitive dependencies no longer exist.

Rust commits much more strongly to backwards compatibility than a language like Python. Deprecating something in the stdlib would be a big deal.

The fact is that in practice, for most “standard” functionality that isn’t in the stdlib, there are well maintained, well vetted crates written by well known authors (or even developers of the stdlib). These are not hard to find, either by asking around or looking at what other crates use.

Rust’s stdlib is consistently of high quality. I can use everything in it without worry or concern. I can’t say the same about Python.

Rust has already deprecated stuff in stdlib, though. It gets tagged as deprecated, and an alternative is generally provided, but the deprecated function sticks around so that stuff that uses it doesn't break. Seems like the best solution to me.

Yeah this is true, but to my knowledge that’s never been done since 1.0 with an entire module, just certain functions (could be wrong, but I have never seen it).

Keeping deprecated functions around still requires some maintenance burden, because you can’t break them just because they’re deprecated. That maintenance burden might become pretty extreme if we’re talking about something as complicated as an HTTP server module, as some folks are asking for in this thread.

I also personally don’t want to see the standard library littered with failed and deprecated experiments. In addition to the maintenance burden, it adds confusion when you’re learning the language or trying to discover how to do something.