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.

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, Add Comment.
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.