Hacker News Reader

Comment by mike_hearn | Hacker News Reader

Go is developed inside Google where all dependencies are checked into their global version control repository. There are literally no versions inside the Google codebase - everything is compiled at head. If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project!

Given this background and the Go designers focus on Google's internal needs, it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)

View on HN

> If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project!

The alternative is of course supporting dozens or hundreds of copies of a library and every possible commit hash of said library. I contracted at a python shop that had 81 versions of a single library in use all pinned at different versions. The reason I know this is that I had the great joy of dealing with upgrading all of them after a critical hole was not only discovered (the company knew about it for some time, but just didn't want to bother updating all those apps) but exploited... repeatedly.

> it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)

If by "fixed" you mean there are dozens of solutions to pin versions -- then yes. If you mean baked into the go tool, then no.

But - but! Saying that you want your org to use one version of a library at a time is one thing. Saying that you want your code to use the latest version of every library is another thing altogether, however, and that's what "no version for github code" does, right?

"One version per org" means "upgrades are harder, but patches are easier and you don't need to deal with different quirks of different versions at the same time and you don't get problems using 2 components that need 2 different versions of some other thing in one process etc."

"Latest version, always" means you have no way to even build the latest version of your thing that was tested and is known to compile and work. Kinda sucks, I think.

Yes, I didn't pass judgement on the approach. It works well enough for Google and avoids problems with e.g. ELF symbol conflicts. For development out on the open internet you do need some way to specify versions so it's a puzzling lack, but "if it works for Google it works for you" does seem to be a recurring theme in the Go design.

> Given this background and the Go designers focus on Google's internal needs

Does it mean the community isn't a priority? this vertical relationship between the Go team and the community could doom the language as fast as it was made popular, that's my opinion.That's a real issue.

That has always been the point of go. A better way of writing code the 'Google Way' It is really useful outside of that (I use it for everything other then video games), but it was always a language to help them get their work done faster.

Reply on news.ycombinator.com