5 ms·

Go mod is a gigantic pig's breakfast. It would work OK if everyone was on it already, but everyone is not on it already. If I took a survey of every go.mod fil

Go mod is a gigantic pig's breakfast. It would work OK if everyone was on it already, but everyone is not on it already. If I took a survey of every go.mod file and looked at the versions, more than half would still be that absurd, un-eyeballable, merge-review-hostile, another-arbitrary-c-hacker-mini-language, shas-upon-shas version string that the "insane amount of thought" landed on because it assumes everyone is already conformant. The ugly corner case for "unversioned" dependencies is the main case. The "insane amount of thought", as is the norm for the Golang team, involved a gymnastic demonstration to evade (1) any serious consideration of prior art in use whatsoever, and (2) entertaining not even the slightest concept of how shitty it would be to impose massive externalities on everyone else. Even an apologetic tone would have made the pill less bitter. Or better yet, blessing godep. Or copying Maven wholesale. Or Bundler. I don't care, because what happened has vapourised millions of developer hours chasing down completely unnecessary versioning issues.

ithkuil 6y ago
It's a delicious breakfast but, served for dinner. I love the mechanics of it. Most of what you describe is the result of having waited ages before implementing it, and the resulting prolonged migration period, exacerbated by the relatively decent (but not perfect) backward compatibility with pre-modules code. Prior art isn't perfect either: I'm happy somebody tried something different from centralized naming systems or almost-but-not-quite federated artifact collections (such as the various maven repos). There is already a global system to get hold to unique names: the domain name system. For better or worse, that's a solved problem, let's not create new naming arbiters
- jacques_chester 6y ago
  > Most of what you describe is the result of having waited ages before implementing it Except we already had godep. It worked. It was in widespread use. > exacerbated by the relatively decent (but not perfect) backward compatibility with pre-modules code. My experience has been that the backwards compatibility has been a nightmare. It forces itself on any downstream repository, whether or not that repository wishes to participate. Plus it does very poorly on diamond dependencies, giving error messages about as scrutable as the I Ching. If your answer is "they're doing it wrong", take it up with the Kubernetes and go-client maintainers, because I can't change what they are doing. > There is already a global system to get hold to unique names: the domain name system. For better or worse, that's a solved problem, let's not create new naming arbiters Versions are not addresses. Addresses are not versions. You may find a version at an address, but addresses are not versions. Docker did the same thing with image references and they too created a pig's breakfast. The difference was that they didn't have prior art to compare to and it was an oversight obvious largely in hindsight. I do not extend the same credit to Russ Cox.
  - ithkuil 6y ago
    > Except we already had godep. It worked. It was in widespread use. > un-eyeballable, merge-review-hostile, another-arbitrary-c-hacker-mini-language, shas-upon-shas version godep shared the same problem. We can argue that godep was good enough and the Go maintainers handled the situation poorly with this whole "ask community and then ignore the community" trick. But you're focusing on the transition; if this system had been part of Go 1.0, I would have had nothing bad to say about it. I'm not arguing the the transition process wasn't a mess. I'm arguing that it became a mess precisely because they wanted to attempt backward compat. They could have said "this is go 2; if you want to use your library with go 2 you have to use this standard, tag your release, or upload it to some central index"
  - Thaxll 6y ago
    godep was awefuly slow and buggy.
    - swagonomixxx 6y ago
      Will have to second this. I didn't find godep more usable than glide, and I find vgo (current Go module implementation) to be far superior to godep.
entha_saava 6y ago
> The "insane amount of thought", as is the norm for the Golang team, involved a gymnastic demonstration to evade (1) any serious consideration of prior art in use whatsoever "We never do what those Java 1xers do, because we are blue collar 0.01xers furiously copy pasting code"

ithkuil 6y ago

It's a delicious breakfast but, served for dinner. I love the mechanics of it. Most of what you describe is the result of having waited ages before implementing it, and the resulting prolonged migration period, exacerbated by the relatively decent (but not perfect) backward compatibility with pre-modules code. Prior art isn't perfect either: I'm happy somebody tried something different from centralized naming systems or almost-but-not-quite federated artifact collections (such as the various maven repos). There is already a global system to get hold to unique names: the domain name system. For better or worse, that's a solved problem, let's not create new naming arbiters

jacques_chester 6y ago
> Most of what you describe is the result of having waited ages before implementing it Except we already had godep. It worked. It was in widespread use. > exacerbated by the relatively decent (but not perfect) backward compatibility with pre-modules code. My experience has been that the backwards compatibility has been a nightmare. It forces itself on any downstream repository, whether or not that repository wishes to participate. Plus it does very poorly on diamond dependencies, giving error messages about as scrutable as the I Ching. If your answer is "they're doing it wrong", take it up with the Kubernetes and go-client maintainers, because I can't change what they are doing. > There is already a global system to get hold to unique names: the domain name system. For better or worse, that's a solved problem, let's not create new naming arbiters Versions are not addresses. Addresses are not versions. You may find a version at an address, but addresses are not versions. Docker did the same thing with image references and they too created a pig's breakfast. The difference was that they didn't have prior art to compare to and it was an oversight obvious largely in hindsight. I do not extend the same credit to Russ Cox.
- ithkuil 6y ago
  > Except we already had godep. It worked. It was in widespread use. > un-eyeballable, merge-review-hostile, another-arbitrary-c-hacker-mini-language, shas-upon-shas version godep shared the same problem. We can argue that godep was good enough and the Go maintainers handled the situation poorly with this whole "ask community and then ignore the community" trick. But you're focusing on the transition; if this system had been part of Go 1.0, I would have had nothing bad to say about it. I'm not arguing the the transition process wasn't a mess. I'm arguing that it became a mess precisely because they wanted to attempt backward compat. They could have said "this is go 2; if you want to use your library with go 2 you have to use this standard, tag your release, or upload it to some central index"
- Thaxll 6y ago
  godep was awefuly slow and buggy.
  - swagonomixxx 6y ago
    Will have to second this. I didn't find godep more usable than glide, and I find vgo (current Go module implementation) to be far superior to godep.

entha_saava 6y ago

> The "insane amount of thought", as is the norm for the Golang team, involved a gymnastic demonstration to evade (1) any serious consideration of prior art in use whatsoever "We never do what those Java 1xers do, because we are blue collar 0.01xers furiously copy pasting code"