I think you should generally be using the latest version of Go

April 27, 2020

At first I was going to write an entry about what versions of Go are packaged with various Linux distribution versions, FreeBSD, and so on, to go with my recent entry on Go on OpenBSD and the Go wiki's OpenBSD page, which directly lists the information for OpenBSD ports (OpenBSD 6.6 has Go 1.13.1). But the more I think about it, the less I think this should matter to you if you do a fair amount of work in Go or at least make significant use of Go programs that you regularly update and build from source yourself (even with 'go get'), as opposed to downloading pre-build binaries for things like Prometheus. Instead I think you should generally be using the latest released version of Go, even if you have to build it yourself, and mostly ignoring the version packed by your Unix distribution.

(Building Go from source is not that hard, especially on well supported platforms.)

The obvious current reason to use a current version of Go is that Go is in the middle of a big switch to modules. Relatively recent versions of Go are needed to work well with modules, and right now module support is improving in every new version. If you're using Go modules (and you probably should be), you want an up to date Go for the best support. But eventually everyone's packaged Go versions will be good enough for decent module support and this reason will fade away.

The first general reason to use a current version of Go is that new releases genuinely improve performance and standard library features. If you use Go significantly, you probably care about both of these, although you may not want to immediately jump on new patterns of Go code that are enabled by new standard library features. And Go minor releases fix bugs (sometimes including security issues), so you probably want to be on the latest minor release of your Go major release.

(Mention of minor releases brings up support. Currently, Go officially supports only the two most recent major releases, per Go's Release Policy. Bugs and security issues in either the Go compiler itself or the standard library probably won't be fixed for unsupported versions. Unfortunately, security issues do happen.)

The second general reason is that other Go packages and modules that you may want to use may themselves use (and depend on) new features in the standard library. Go's standard library documentation marks which Go version every new thing was introduced in, but it's up to people to both pay attention and decide if they care. Especially, a third party package that's under active development may not preserve much compatibility with versions of Go that are no longer officially supported.

(If you care about your own code building on old Go versions, my view is that you should be actively checking this, for example by routinely building it with the oldest Go version that you care about. It's all too easy to absently start using a new standard library feature that's more recent than you want.)

One implication of this is that the officially packaged version of Go shipped with long lived Linuxes, such as Ubuntu LTS, is likely going to get less and less useful to you over time. The most recent Go version available standard in Ubuntu 18.04 LTS is Go 1.10, for example; it's thoroughly out of support (and doesn't support modules), and probably any number of things no longer build with it.


Comments on this page:

By dozzie at 2020-04-28 05:32:57:

And this is the problem with modern developers, this is what I hate. It's less and less of languages that give you forward compatibility, where you can use current code on an old distribution (as opposed to backward compatibility, where you can run old code on new releases). Python 2.x was like that, Perl was like that for a long time. Modern Python 3 code generally requires you to make mess of your OS by side installing stuff, so you can't make proper use of your OS packages (and in consequence, repeatability of building or installation).

The languages move far too fast, but they don't give much in return, it's all almost unnecessary bells and whistless.

With a sysadmin hat on, I really see the major problem as "things not supporting co-installation." For Go, the Windows installer doesn't even officially support upgrades.

So downstream developers' options are to use Docker, keep an obsolete Go as system version, aggressively drop support for unsupported Go versions, or risk inadvertently breaking things in old versions they're nominally supporting.

I'm probably going to go the Docker way eventually; if someone is on Ubuntu LTS desktop, they shouldn't need a "build a toolchain" yak shave to get started.

By cks at 2020-04-28 11:47:59:

Although it doesn't seem to be officially documented, the Go binary tarballs are all completely filesystem position independent, and so support co-installation. You can unpack them anywhere and call the top level directory anything you want to (eg 'go-1.14.2'), and everything works. Very old versions of Go had the install path burned into them and so couldn't be relocated like this, but the Go toolchain has been location independent for a while now.

(I believe this will be true of a system Go, too, although I haven't tested it.)

By Greg A. Woods at 2020-04-30 14:02:19:

I'm with dozzie about languages evolving too fast, but indeed as Chris says, there's no problem with having multiple versions of Go installed, at least on the platforms I care about and use.

Python is worse, but not horrible -- it's usually the people doing the packaging that screw it up the most -- the language implementation is mostly agnostic. The bigger problem is that Python is interpreted, and the way that works on Unix/POSIX often means that the programs need to know where the interpreter is installed (i.e. what its exact and full pathname is); and that often means modifying programs and scripts at install time, and reinstalling them if the interpreter is changed. This is never a problem with a compiled language like Go.

Also with Go, so far, and in my very limited experience, the language has evolved in such a way as to be relatively backward compatible (though third party dependencies are kinda messed up by the late introduction of better modules support). In my also limited experience it seems Python also did pretty good with language compatibility within major numbers.

Written on 27 April 2020.
« My views on SystemTap as compared to eBPF for Linux kernel instrumentation
Dealing with my worries about Django and HTTP Basic Authentication »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Apr 27 22:47:42 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.