[jcgl]

One man's bloat is another man's batteries-included, I guess?

My argument would be that if a more featureful standard library could get Rust closer to the superior dependency culture of Go, it'd be worth it. As-is, Rust dependency trees are just wild.

[vsgherzi]

The rust team is already stretched pretty thin. A larger library is going to put more pressure on them. These libraries are already maintained and used. The rust project should just directly, fund, Shepard and guarantee a level of quality for the packages. The foundation has started some of this with the maintainers fund. No need to force it all into the std lib. Go has experienced breaking issues with changes in the crypto library causing churn in the ecosystem.

[jcgl]

Point taken about the core team being stretched thin. But I don't see how the "increase stability of some core crates" is enough to change the packaging practices/culture. Maybe I'm wrong, but you really don't get those ecosystem benefits unless the ~entire ecosystem buys into that set of packages. Which really doesn't happen without stdlib.

Also, I think that your example of Go's breaking crypto changes misses the forest for the trees--the stdlib has been incredibly stable through its history, and the vast majority of packages just never have to worry about it. I'm honestly not aware of a language out there with similar adoption, featureset, and robustness. More to the point, I'm not aware of a language out there with a more reliable stdlib that permits the ecosystem to have small dependency graphs.