Isn't it at least partly explained by wanting to allow implementations of this functionality to evolve more rapidly than they could if they were in the stdlib and thus reach good solutions more rapidly? getopt in particular seems like something that programmers haven't reached a consensus on despite 40 years of experimentation.
I would beg to differ with this. The kind of functionality expected from Getopt is fairly standard these days. I also disagree that features like getopt really need to 'evolve' much at this point in time. At the risk of courting controversy here, I'm going to confess that often I just don't want the community involved in the development of a language. On a project I inherited recently ( with the mission to save ) I unfortunately had to suffer using Typescript. If you look at the community discussions regarding the language's future direction you'll be treated to the uninformed arguing with the ignorant about the language's direction.
Every time I download an external crate, I have to learn a different developer's way of doing things, suffer their idiosyncratic ways of creating an API and potentially expose myself or my application to a new set of vulnerabilities. The more I can get away with not doing this, the better.
More often than not, absolutely. It requires a much higher level of competence to design a language and develop a functional compiler than it does to design libraries. There are packages in Node with millions of downloads, packages that are basically ubiquitous in certain domains that are riddled with bugs, with terrible interfaces and documentation. I can even think of libraries I've worked with in Java/C/.net/etc that are just horrific... If the languages themselves were as badly designed as the average library, they'd never succeed.
Language design and compiler implementation are definetely high-competency skills, but they don't necessarily correlate with library design skills.
For instance, http client and server libraries are often in this gray area of uncertainty about whether they should be in the stdlib or not. Is this something language designers or compiler implementors have a lot of experience in? I would say not; sending and serving http requests are not something compilers need to do. Or take GUI libraries, what do language designers know about that?
I also know of many bad third party libraries, but there are tons of examples of really awful parts of standard libraries. The original date/time APIs in Java are a mess (they finally fixed this by in essence bringing in a third party API). The ssl bindings in the Ruby stdlib were a common source of bugs back when I was paying attention to this (maybe they've fixed it), same thing for the built in http stuff. Someone else mentioned the similar weakness of python's built in http, such that most people use a third party library instead. Even the java collections APIs are pretty poor such that people often augment them with things like guava or apache libraries.
My point is just that developing good libraries is a hard thing and I don't see any reason to think language designers or compiler maintainers are any better (or worse!) at it than other people. There isn't really a shortcut, you can't just cede authority to the powers that be on the core language teams, you just have to evaluate the quality of libraries for your use case yourself.
You've made a very good point that proficiency in developing compiler infrastructure does not imply that you're qualified to develop every specific aspect of a standard library. Date/Time, as you pointed out, is a very good example of this. It's a very complex domain that requires specialised knowledge.
I'll counter this by saying that one aspect of language design is choosing the scope of the project, and deciding how best to implement a standard library targeting the language's intended domain. If your language is designed to implement web servers, then developing a GUI library might be a poor investment. Consequently, if your language is designed for implementing system applications, then investing time and talent into developing things like FFI, Filesystem and GUI functionality are just the prerequisites to the language being useful in its intended domain.
Yes I do sympathize with this in that, put bluntly, I'd also prefer that a programming language be developed by a smaller team of highly skilled people, as opposed to making the process as accessible as possible. But I really think there are ways for everyone to help out while retaining the feature that the most important and challenging parts are contributed to by the appropriate people, without upsetting anyone. And I think it's possible that Rust might be a shining example of such a thing. Clearly, in modern western society, it's hard to avoid this discussion acquiring a political dimension. And honestly that is something the open source community might need to address openly and attempt to do a better job of schism-avoidance than other areas of society.
