[SamWhited]

> The main problems I've had with go modules are fast-and-loose upstreams that happily rewrite history. go mod detects this and stops the world, and you have to manually edit go.sum.

This is really irritating. I have the same problem with TLS: every time a malicious actor tries to manipulate my connection and steal my cookies I get an error page and can't do online banking anymore!

Sarcasm aside: this is not a problem with Go modules. This is a problem with the libraries you're using and you should avoid those projects until they get their act together.

[kasey_junk]

Internal libraries are a huge pain to build now. I don’t need the rigor of semantic versioning for this, it just gets in the way. My act is together, I have tests that confirm my libraries work, I have a idempotent versioning system that is automatic (git sha) and if something gets merged to master that is my stamp of approval that it works.

Between the versioning behavior and trying to figure out how to document transitive dependencies correctly go mod has made my life as a maintainer harder.

[knownunown]

It sounds like the replace syntax might help here. It allows you to forgo semver+version control and depend on modules on your local disk. https://github.com/golang/go/wiki/Modules#can-i-work-entirel...

[dragonwriter]

From the point of view of someone considering what to use, it's often of fairly minimal significance if a problem comes from the language ecosystem or from the language technology.

[sagichmal]

These two things are not comparable.

[Thaxll]

This prevent things like Nodejs package hijacking. I think it's a pretty big deal tbh.