Re:Keeping your Go modules compatible
by closeparen on Tuesday July 07, 2020 @11:09PM
(#23766546)
Yet asking Glide or Dep to solve semver for a typical medium-sized Go service would peg your CPU fans for an hour or two and usually fail.
Re:Keeping your Go modules compatible
by plorkyeran on Wednesday July 08, 2020 @01:21AM
(#23767106)
And ask NPM to install a package and it's able to pick a version of all eight hundred dependencies that package pulls in within a few seconds.
The one and only "internet meme" I ever created while I was waiting for dep to finish, and is about dep being slow :-)
https://www.reddit.com/r/golang/comments/7c1dj9/the_real_rea...
Of all the package systems I've worked with, I've had the least about of trouble with Go modules. Some aspects can be a bit confusing and idiosyncratic as first, but overall I found it quite easy to understand and reason about (which is important especially when things go wrong! I still remember my "I can't figure this out, fuck it, I'll rm -rf shit until it works"-Bundler days all too vividly).
[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)