I disagree here. Coming from Ruby, there are lessons to be learned. Ruby has a large stdlib, like you seem to want. But a lot of stuff in there is outdated. So

I disagree here. Coming from Ruby, there are lessons to be learned. Ruby has a large stdlib, like you seem to want. But a lot of stuff in there is outdated. So much, that many, even most, people, projects, frameworks immediately replace them with a community version. Sometimes because they are actually better maintained, more stable, faster, cleaner and more secure than the ones in stdlib. A similar thing is seen in Ruby-on-Rails, which adds features and even entire frameworks with every release, but which many people swap out for their own preferred lib almost immediately. This is inevitable and obvious. And, IMO should be embraced: deprecate them from stdlib, and leave it to "the community". > They will (semi)randomly pick some third-party Again good lessons can be learned from Ruby (gems) here. People will pick a "random" one only if there are no canonical, defacto-standard libs (gems) out there. But for some gems there is a clear, singular goto option and everyong will pick that, turning it into something of a stdlib. A good next step would, IMO, NOT be to then pull those libs into the stdlib, but, instead, to make the "not-fully-stdlib-but-also-not-random-community-provided" into a distinct category of libs.