A stable Unix updating its version of Go isn't straightforward
Recently, I was implicitly grumpy at Ubuntu 18.04 LTS for not updating its Go version from Go 1.10. The reason to want an update is straightforward; Go 1.10 doesn't support modules and you need module support. However, after thinking about it more I had the realization that a stable Linux or Unix distribution updating Go versions within a single release isn't as straightforward as it looks. In fact, Go 1.10 is a particularly awkward version to update from (as will be Go 1.15).
Most distributions that are going to update something within a stable release want the new version of whatever it is to be a more or less drop in and transparent replacement for the old version. On the surface, the Go 1 compatibility guarantee seems like Go should be fine here, since new versions of Go will compile your code so that it does the same thing as your current version. However, that isn't all that people care about. In order to be a drop in replacement, people need to be able to develop with a new version of Go in the same way and it should have the same broad runtime behavior (or better). Neither of these are covered by the Go 1 compatibility guarantee, and in fact the Go team have explicitly stated that the Go toolchain is not.
For Ubuntu 18.04 and Go 1.10, there are two issues. First, going
from Go 1.15 and below to Go 1.16 is a breaking change in tool
behavior for existing setups, because the default behavior changed
to modular mode even under $GOPATH/src. In Go 1.10, everything was
in $GOPATH/src and you had to work there (and any go.mod files were
ignored); from Go 1.16 onward, none of that works by default. Even
Go 1.13 might be a behavior change, since it enables module mode
in the presence of a
go.mod file even when you're under $GOPATH/src,
which means that some programs may build differently between the two
Second and smaller, from Go 1.12 through Go 1.15 Go programs reported a higher RSS, which could (and did) cause issues in environments where these were either monitored or limited. Going from this range to Go 1.16 improves things (which is a change but not one people are likely to object to), but of course that gives you the Go 1.16 module behavior change. This change in runtime behavior from Go 1.10 (or Go 1.11) might be considered an acceptable change in some Unix distributions, but there are others that would probably reject it as too much.
If both behavior changes are unacceptable in a stable release, then Go 1.10 could only be updated to Go 1.11, which is hardly worth it (1.11 is far out of support and I'm not sure how good its module support was). Ubuntu 20.04 has Go 1.13, which could probably be updated to Go 1.15 but certainly not to Go 1.16. Debian stable has Go 1.11 which could theoretically go to Go 1.12 but probably not Go 1.13 given Debian's cautious attitude on changes.
(I haven't checked CentOS 8 but it's probably similarly constrained in Go versions. I don't know if FreeBSD ports are considered stable in this same way.)
To full time Go programmers, much of this may seem picky on the part of Linux distributions. To the users of the Linux distributions that advertise stability (and to the distributions themselves), it's not. People count on being able to routinely apply package updates without careful testing and surprise changes in behavior that break workflows and other things.
(In a way this is another aspect of frequent versus infrequent developers. If you're a frequent Go developer, you probably already have your own toolchain. It's the infrequent Go developer that is probably using whatever Go toolchain comes with their OS because it's usually good enough.)
PS: I'm still going to be sad that Ubuntu 18.04's standard version of Go isn't really good enough any more, but that's just because it would make my life at work slightly easier if it was.