Part of what we do to balance this out is to have the team make some of those third party packages; the regex crate is a good example of that. It’s still maintained by the team even if it’s not in the standard library itself.
> The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust.
More importantly, due to Rust's backwards compatibility guarantees, you can never remove something once it has been added.
I vaguely wave towards Python's 3-5 built-in "get data from a URL" libraries as an example of a bad route that this can take.
The regex crate can release a backwards-incompatible version 2 without destroying the entire ecosystem since multiple versions of a crate can co-exist in the final graph of dependencies.
> The standard library is locked to Rust - you can't issue a new major version of stdlib without having a major version of Rust.
How often do you see that actually being a problem? Rust releases new versions on a regular cadence. Just how often do you imagine the regex crate actually needs to be updated? Or how about the random number generator crate?
> Besides the impact of not being in stdlib is very low except for discovery.
I always find this an interesting argument. We've seen node.js etc. packages be compromised many times, or even completely vanish (left-pad)? How much confidence can I have that any individual package hasn't been compromised somehow? How much confidence can I have that random dependencies aren't suddenly going to enter my build chain. That left-pad situation was classic. So many things got broken, not because they'd picked up left-pad, but because dependencies of dependencies of dependencies relied on it (and so on down the line...)
There was that situation just a month or so ago where a developer just didn't want to maintain their package any more, had someone volunteer, who then compromised it with a crypto-miner.
Now on top of that licensing gets to be a whole bunch of fun as soon as you step outside the stdlib. For every crate you add, you need to do a licence audit, and for each and every one of its dependents, and its dependents dependents. Amazon, for example, has a black list of licenses. You can't use any software licensed under one of them, for whatever reason the lawyers have about each one.
Specifically, the authors are still deciding the right way to architect the library for the myriad of uses that Rust has.
> or even completely vanish (left-pad)
In 99.99% of the cases, you cannot remove a crate from crates.io; you can only prevent new projects from adding the crate as a dependency. The other 0.01% is because of legal reasons, and there's not much to be done about that.
> For every crate you add, you need to do a licence audit
Your concern may be founded in the difficulty other languages' package managers present. With regard to C/++, there really isn't package management at all, making package inclusion a big decision. With regard to Ruby (for example), the package management is actually pretty unreliable and terrible given how many gems require system libraries and incompatibilities of gems across Ruby versions.
With Rust, the package manager is very good. So it's not a problem in practice.
