21–30 of 57 posts
there's something that I just don't get about golang modules, I don't know what it is but they don't click with me it might well be something tacit that golangers learn from each other directly? or otherwise it's so obvious and simple and I just haven't realized? it feels like it's the kind of thing that just clicks one day possibly after a few years
Earlier quoted context omitted.
> Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. Go modules is probably the most well-wrought versioning system for a programming language. The amount of thought that went into it is insane. https://research.swtch.com/vgo
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 a…
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
Earlier quoted context omitted.
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 a…
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…
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.
Earlier quoted context omitted.
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…
> 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 t…
> 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"
Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. The language as a whole despite being now universally used as the backbone of cloud native, it honestly looks like it's intentionally designed to be horrible and insulting for anyone with sensible mind. Every obvious right de…
> Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. Go modules is probably the most well-wrought versioning system for a programming language. The amount of thought that went into it is insane. https://research.swtch.com/vgo
[1] in fact it's only NP-hard if you add an optional aditionnal constraint: that every dependency must have a single instance even if it's a transitive dependency from several dependencies with conflicting requirements. If you allow different major version of the same dependency to coexist in the dependency tree, it becomes a straightforward linear problem while still behaving like every single other package manager in existence for the end-user. Now that's a well thought system! (And there at least one language, pretty popular these days on Hacker News, which does exactly this)
Earlier quoted context omitted.
> Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. Go modules is probably the most well-wrought versioning system for a programming language. The amount of thought that went into it is insane. https://research.swtch.com/vgo
It's the most over-though versioning system ever actually. It's a rare mixture of NIH syndrome and obsession to a specific theoretical concern. Yes semver dependency management is NP-hard[1], but lawn mowing is NP-hard too, and yet that doesn't seem to stop anyone else! [1] in fact it's only NP-hard if you add an optional aditionnal constraint: that every dependency must have a single instance even if it's a transiti…
Reading these blog posts, you get see Go's simplicity start to unravel with modules. Uncomparable structs? Type checking workarounds? You start to wonder if these bandaids would be necessary in a generics world. For the record, I'm indifferent on the chosen module solution being right or wrong. My ideal module tool is something like npm, but it shows me the impact: diff the module changes, look at my code, and tell m…
Reading these blog posts, you get see Go's simplicity start to unravel with modules. Uncomparable structs? Type checking workarounds? You start to wonder if these bandaids would be necessary in a generics world. For the record, I'm indifferent on the chosen module solution being right or wrong. My ideal module tool is something like npm, but it shows me the impact: diff the module changes, look at my code, and tell m…
Gah in every language I want that interface comparison tool, and I keep on being disappointed.
Earlier quoted context omitted.
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…
> 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 t…
> When you run into a case where you want to add a method to an existing interface, you may be able to follow this strategy. Start by creating a new interface with your new method, or identify an existing interface with the new method. Next, identify the relevant functions that need to support it, type check for the second interface, and add code that uses it. I like this pattern, and I have used it. The issue I have…