alt Hacker NewsIt turns out that the needs of Google overlaps significantly with the needs of software engineers outside Google. That argument could have been valid for a while after its initial release. But now it is just a lazy argument today.
I think batteries included is a better strategy. To the degree where I think Rust should reconsider this decision.
Replies
It also means that everything is (over) optimised for Google's usecases, but not general purpose applications
I came across this problem pretty directly a couple of weeks ago - I wanted to see if I could port a small C program to Go, where one of the needs is to create gzip archives. But the Go stdlib insists on extraneous padding that breaks the backwards compatibility requirements of my program.
The padding isn't needed, it isn't useful, and you can't opt out of it. So the whole program went in the bin and I have resumed maintaining it in C
This is one of dozens of situations I've experienced where Go's allegedly pristine stdlib design has kicked me in the nuts
Rust likes to do things neat and proper and inclusive and community and zero-cost (or ALARA [as low as reasonably achievable]), and so on.
But there's no theory of standard library that they could implement. Shipping things together makes sense, but the maintenance burden is already significant, and there's also no theory of "ethically cloning open source maintainers".
I'm also quite squeamish when I think about all the unvetted dependencies, so yes, there's definitely a need, but I don't think slapping a stdlib tag on millions of lines of code would lead to great things.
But sure, I think someone could champion the case to introduce a process for adding projects to the standard packages. The projects would need to show some competence, commitment to quality and security. And the process obviously needs to have an orderly procedure for deprecation, and for "non maintainer updates" (like Debian has, for example).