IMO, Golang does the best job of maintaining a high quality standard library. I disagree that modules should be moved into the external package ecosystem. However, Go isn't preinstalled on most systems like Python.
I have to develop enterprise software that runs across a wide range of platforms, and being able to take advantage of the fact that Python is pre-installed on all of these systems with its standard library is a godsend.
Go programs are statically built as fat binaries. That basically solves the problem in itself.
Python scripts rely on a (very) large shared constellation of thing being present on the host system. Change one of these and you might break some stuff.
It’ll be interesting to see how Go (Rust, and other new languages) evolve and if they can avoid some level of package decay when they reach the age of Python, Java, etc.
I’ve been working with go a lot lately and they seem really focused on not letting this happen. Every single thing in the language and standard library seem completely focused on minimalism and compiler time. The standard lib is unlikely to change all that much and people are not picking the language for a bunch of convenience features.
Third party package problems will be an issue at some point but that’s more due to them be so focused on minimalism they don’t have clear guidance on setting up and maintaining packages.
3rd party packages are already a problem because a github repo shouldn't be treated as a dependency source. Gomod solves some problems but still uses git repos as the source.
The primary reason Go can get away with this strategy is because the Go community actively promotes fewer dependencies = better. So if you write Go you have to often accept the fact that the second you add a 3rd party dependency that you're now officially on your own if that dependency breaks or becomes unsupported.
This is not necessarily a bad thing. But in order to move software forward I still think we can do better than to push this responsibility to all individual end users.
This is one area where I feel like most popular languages today still fail compared to CPAN. CPAN's value was not just packaging and distribution, it was an integrated test report pipeline and infrastructure, actively managing and gatekeeping of library maintainers, CPAN mirroring functionality, and easy acceptance of bug reports and user feedback against a library.
I think this is mostly due to the 1.x guarantee that anything old will compile on anything new. I don’t know if Python or others formalized the same guarantee, but I don’t remember any issues 2.2 - 2.15.x (of course 2-3 is infamous). However 3.3+ (when I joined the py3 crew from py2) I don’t recall any either.
My experience with Go has been equally pleasant (though it does require more boilerplate for commonly accepted reasons in the community), but in no way unique.
> Golang does the best job of maintaining a high quality standard library.
Why? Not only Go. Clojure as well. Clojure's standard library is incredibly consistent and stable. Documentation pretty dry though. That's the only complain I can think of.
I have to develop enterprise software that runs across a wide range of platforms, and being able to take advantage of the fact that Python is pre-installed on all of these systems with its standard library is a godsend.