An unexpected risk of using Go is it ending support for older OS versions

August 23, 2017

A few years ago I wrote The question of language longevity for new languages, where I used a concern about Go's likely longevity as the starting point to talk about this issue in general. The time since then has firmed up Go's position in general and I still quite like working in it, but recently a surprising and unexpected issue has cropped up here that is giving me some cause for thought. Namely, the degree to which Go will or won't continue to support older versions of OSes.

(By 'Go' here I mean the main Go implementation. Alternate implementations such as gccgo have their own, different set of supported OS versions and environments.)

Like most compilers, Go has a set of minimum version requirements for different OSes. It's actually fairly hard to find out what all of these are; the requirements for major binary release platforms can be found here, but requirements for platforms may only show up in, for example, the Go 1.8 release notes. Probably unsurprisingly, Go moves these minimum requirements forward every so often, usually by dropping support for OS versions that aren't officially supported any more. A couple of topical examples, from the draft Go 1.9 release notes, are that Go 1.9 will require OpenBSD 6.0 and will be the last Go release that supports FreeBSD versions before 10.3 (theoretically Go 1.8 supports versions as far back as FreeBSD 8).

(The best platform requirements documentation appears to be in the Go wiki, here and here, which was a bit hard to find.)

I'm sure that for many people, Go's deprecation of older and now unsupported OS versions is not a problem because they only ever have to deal with machines running OS versions that are still supported, even for OSes (such as OpenBSD) that have relatively short support periods. Perhaps unfortunately, I don't operate in such an environment; not for OpenBSD, and not for other OSes either. The reality is that around here there are any number of systems that don't change much (if at all) and just quietly drift out of support for one reason or another, systems that I want or may want to use Go programs on. This makes the degree to which Go will continue to support old systems somewhat of a concern for me.

On the other hand, you can certainly argue that this concern is overblown. Building Go from source and keeping multiple versions around is easy enough, and old binaries of my programs built with old Go versions are going to keep working on these old, unchanging systems. The real problems would come in if I wanted to do ongoing cross-platform development of some program and have it use features that are only in recent versions of Go or the standard library. Life gets somewhat more exciting if I use third party packages, because those packages (or the current versions of them) may depend on modern standard library things even if my own code doesn't.

(If my program doesn't use the very latest shiny things from the standard library, I can build it with the latest Go on Linux but an older Go on OpenBSD or FreeBSD or whatever.)

Comments on this page:

By Jinks at 2017-08-23 05:59:53:

Given that Go builds either entirely or at least mostly static binaries, there's also a good chance that the generated programs will still run on older platforms, even when the toolchain requires a more up to date system.

At least in my environment the dev and personal boxes tend to be the most updated systems, geared more towards "new shiny toys" than towards absolute stability.

By cks at 2017-08-23 23:50:20:

Unfortunately, it looks like Go usually changes its minimum requirements in order to do things that affect all of the programs built by the new toolchain, not just the toolchain itself. This means that you can't safely build programs for an old environment with the new toolchain; even statically linked they may do things like use CPU instructions that only exist in newer CPUs, include new types of ELF segments in the executable, or use new system calls without fallbacks.

(I wrote up some examples here, since I got curious about the specifics of why Go was dropping support for various older things.)

Written on 23 August 2017.
« Understanding rainbow tables
Why Go changes its minimum version requirements for OSes (and hardware) »

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

Last modified: Wed Aug 23 00:56:31 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.