1. Heavy dependency on Github. AKA Microsoft owns much of the golang ecosystem. Not just the source... The package distribution as well!
2. Many packages are referencing a git (short!) commit hash instead of a version. It still boggles my mind that this is an acceptable practice. Not to mention that git tags can be deleted and recreated... A pinnacle of secure package distribution practices.
3. Stuff like ambiguous imports because apparently nothing enforces proper go.mod files? They are not packages to be compiled after all, they're just repos with some conventional structure (optional)...
Mind you, this is popular production-grade software...
I think this is much worse than even node packages, let alone bundler and rubygems...
2. You complain about commit hashes while simultaneously noting that tags can be deleted and recreated. Hashes are precisely the solution to mutable tags. The "short hash" concern is a red herring; Git uses sufficient entropy that collisions are not a practical concern for dependency resolution.
As for "secure package distribution," go.sum files verify files verify consistent downloads. What additional security do you believe centralized registries provide?
3. Can you provide a concrete example of an ambiguous import you've encountered? I'm not familiar enough with Go to understand this criticism.
Exactly. This 'social phenomenon' should have been taken into account when designing a packaging system so that the language's ecosystem does not end up entirely dependent on Microsoft due to 'social reasons'.
> The go.mod file you linked references ~14 different Git hosts
Of which the non-github ones account to what... 15% of the deps in the file?
> You complain about commit hashes while simultaneously noting that tags can be deleted and recreated
Yes. Not using versions (semver) is a bad call, and having people be able to mutate the code of a version is a very bad call. Once a version has been tagged, the only viable choice must be to pull that version and push a new higher version.
> As for "secure package distribution," go.sum files verify files verify consistent downloads
Based on git's hash.
> Git uses sufficient entropy that collisions are not a practical concern
Unless crafted by an adversary? Git's sha1 hashes are not a security tool and must not be used in place of code signing.
They are also not good for versioning, as you can't deduce whether a commit introduces breaking changes. Rubygems has the ability to reference git repos. It's always a pain to update these compared to other semver deps -- you have to go to github and do a comparison between the old and new hashes to try and deduce whether bumping this will break you.
> Can you provide a concrete example of an ambiguous import you've encountered
See end of linked go.mod
