4 ms·

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, J

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.

frou_dh 7y ago
Notably, a number of packages in the Go standard library have officially become "frozen": https://www.google.com/search?q=site:golang.org/pkg/+"frozen" https://www.google.com/search?q=site:golang.org/pkg/+"frozen...
pixelrevision 7y ago
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.
- teek 7y ago
  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.
- nerdwaller 7y ago
  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.

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.

frou_dh 7y ago

Notably, a number of packages in the Go standard library have officially become "frozen": https://www.google.com/search?q=site:golang.org/pkg/+"frozen" https://www.google.com/search?q=site:golang.org/pkg/+"frozen...

pixelrevision 7y ago

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.

teek 7y ago
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.
nerdwaller 7y ago
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.