3 ms·
Honestly, my only complaint about go mod major versioning is just how unintuitive versions after v1 are. While some may disagree about the tradeoffs, I think th
by jchw 5y ago
Honestly, my only complaint about go mod major versioning is just how unintuitive versions after v1 are. While some may disagree about the tradeoffs, I think the reasoning behind it is totally solid, but there are definitely valid complaints about the exact behavior of modules being somewhat confusing. I recall confusion with trying to update a library with no tagged versions, too, for example.
That said, I think people greatly undersell how well Go has done packaging. There’s, again, tradeoffs that are at least arguable; but, I hate when people say things like “Didn’t (npm|apt|cargo|…) already solve this?” Honestly, often times the answer is at best “kind of?” — a lot of these packaging and versioning problems remain without complete solutions. Meanwhile, Go has some novel design choices that set it apart. The module proxy is a slightly unfortunate tradeoff, but Go remains one of the only languages with a good story for mostly decentralized package management. The module proxy is more of a hack that gets you some of the advantages of centralization without strictly depending on it. But beneath that, it’s nice that you can pull packages from basically anywhere with several VCSes.
- fourseventy 5y agoYa I spent an hour once trying to figure out why I couldn't get a dependency to upgrade to the latest version then it finally hit me and I was like "oooooh ya that stupid major versioning path change thing". I find it very unintuitive.
- deleted 5y ago[deleted]