Though I don’t completely deny a small stdlib, this statement just doesn’t make any sense, unless the lib itself is something nobody going to use of course.
The live example here is Go, which has a huge stdlib, and those libs receives regular maintenance by community and Go team. Similar thing is happening to Java, Python, PHP as well.
I don’t know how this
stdlib == dead libraries thing got into people’s mind. A third-party lib is much more likely to die than the one in stdlib. “Lost of interest”, “Lack of time”, “No successor maintainer” to name a few reasons.
Do you depend on a particular lib for your enterprise™ multi million dollar operation? Fork it
If every company has to do something like that, then they may as well build a language/lib by themselves. Why bother trying out a “untested” new one? OR, they may just use the language that provides the complete package they needed. There is a reason for Java EE to exist and grow to that scale.
Language development should always facing the market demand, not just “We are building something cool which features X Y Z”. Nobody is going to use your language if it can not help them make money, quickly. Welcome to the Real World Co., where “untested” and “new” is Risky Factor™.
No, all experience has shown the std is what goes unmaintained
Is this throw-away gigs? I can provide example where security issues is fixed right after discovery.
I’m actually agreed with many view points which supports a small stdlib. It certainly got their own advantage (and of course, disadvantage). Admit those cons and pros will make the community more heather as it makes the goal more clearer. Blindly denying it won’t make the language better, it will only make the community toxic.