I wouldn't exactly call Go's standard library _good_. It's got a lot of stuff in it, which is nice, but the API design ranges from excellent (net/http) to "how much crack?!" (time.Format and .Parse) to not-quite-sufficient (various packages).
And of course, standard library APIs age with time. Perl and Python are good examples. Both ship with packages that were really good in their day, but have long since been superceded by community-created tools. But the core has to keep shipping the old thing for backwards compat and the maintainers are reluctant to add yet another package that does the same thing.
Dependencies have their downsides, but being able to assemble the best of what's out there rather than relying on the best of what was available at some point in the past has a lot of advantages too. Languages with good dependency management seem like the best possible option.
Go's refusal to embrace this is a huge pain point. Dep is a decent start, but without a community actually doing things like releases, changelogs, and all the other things that go into a solid ecosystem, it's a half measure at best.
> Go's refusal to embrace this is a huge pain point. Dep is a decent start, but without a community actually doing things like releases, changelogs, and all the other things that go into a solid ecosystem, it's a half measure at best.
Go has indeed embraced it and is working on `dep` the officially sanctioned dependency manager.
Good is _really_ subjective.
While its definitely better than JS/Node it has some warts.
For example, I find the "time" builtin package to be pretty terrible. Specifically how it does formatting[0]. This method makes the format look like a magic string rather than being an obvious template like other languages would use.
I've found some legitimate bugs[1] in simple functions that don't give me a ton of confidence in it either.
Personally I find the standard libraries in the likes of Python and .NET Core much more comprehensive, intuitive, and reliable.
I often see time.Parse as a common complaint - but my code is much more readable when I can see what the date format looks like, rather than trying to interpret the cryptic syntax which differs from language to language.
It's sure not perfect, and it's impossible to please everyone but I think it was worth the experiment.
