> However, even a minor inconvenience is still an inconvenience.

I do not miss spending 30 seconds untangling my headphones every time I used them nor do I miss trying to find clever ways to wind my headphones back up so as to minimize the likelihood of them becoming tangled. If someone solved this problem well I would use them, but putting my airpods on a charger once a week is a much lesser inconvenience IMHO.

I didn’t have a strong opinion on standard library sizes until I tried Rust, but Rust was not a very pleasant experience because there were not standard packages or even consistent community advice for things as pervasive as error handling or async.

But I understand people have different opinions and that there will never be a standard library that appeases everyone. I don’t think “having a batteries included library” aims to appease everyone either. But mostly I just don’t understand the people who criticize Go for not having enough things in their standard library because Go’s standard library is one of the more useful (which may not be everyone’s ideal).

That makes sense. I guess I usually think of developing policies for this kind of thing to be pretty much what staff would do. I don’t usually expect the CTO to make decisions about how to do testing. To the extent the engineering leadership are to blame, it’s that they were the ones who hired/retained this guy. The buck ultimately stops with them to be sure, but making these kinds of policies seems within the remit of a staff eng.

Welcome to literally any Go thread.

No one is debating whether Go is missing a uuid package from its standard library; the debate is about whether this is indicative of a general trend with the Go standard library (as the gp claimed above).

If you’re arguing as the grandparent did that Go regularly omits important packages from its standard library, then it’s not unreasonable to ask you for your idea of an exemplary stdlib.