Hacker News Reader

Comment by opqpo | Hacker News Reader

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 decision looks like it's intentionally being replaced by a bad one if it's the right path is easier.

View on HN

Something I knew starting out, forgot, and learned again, is that there's a huge liability to spending your entire career working for one company.

There will be things they do so well they aren't even on your radar, and you will have a huge blindspot there. And there are things they tolerate that pretty much nobody else will. So you will either suffer in ignorance or learn some nasty, nasty habits.

Without moving you see no diversity, and without seeing diversity you shouldn't be put in charge of building anything for 'everyone'. You are only qualified for niche solutions, which unfortunately outsiders might not clue in on until they've invested heavily in your ideas.

In college we referred to this same idea (among my peers who were going on through graduate studies, particularly PhDs) as "academic incest", where you aren't sufficiently exposed to a diverse enough set of ideas and end up too narrowly focused or clouded in your judgment.

Ways to overcome it include: moving (in academics, accepting a fellowship at other institutions; as a professional, change jobs); observation (keeping abreast of the latest trends outside your immediate environment and field); community participation (attending conferences, symposia, and similar things; or even forums like this).

But ultimately it requires a recognition that your views, knowledge, and beliefs are, necessarily, constrained by your experiences and that you sometimes have to seek out novel experiences or the experiences of others to change yourself. If you lack the drive for either, or too great a confidence in your own present state, then you're going to be stuck.

> 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 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)

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.

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).

Go does allow coexisting major versions, just not coexisting minor versions.

> Go modules is probably the most well-wrought versioning system for a programming language. The amount of thought that went into it is insane.

appreciated, but i share GP's sentiment.

without the uncalled for bashing though. because package management and versioning is hard. for all the backlash they get, package management in python, ruby, php, nodejs, all makes sense to me!

they make so much sense that, in my opinion, that the situation is akin to picking a side and sticking to it. just like you would for your favorite text editor. you perfectly understand what is going on.

go package management on the other hand makes no intuitive sense!

it took like 3, 4, or 5 long blog posts to explain it to us. and all i got from them is how hard package management truly is. i still can't intuitively do it.

i haven't touched php or nodejs in a while but i will be able to get composer or npm or npx (or whatever it is nowadays) to install something for me, locally or globally. not saying it is done right. what i am saying is i get it!

sorry but something is not right with go modules.

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.

> 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"

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

> 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.

> 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"

godep was awefuly slow and buggy.

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.

This comment would benefit immensely from a single concrete example. As it is, it scans as bluster.

Do you have any specific examples in mind?

Reply on news.ycombinator.com