I think you should generally be using the latest version of Go
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.
My views on SystemTap as compared to eBPF for Linux kernel instrumentation
In the small lobste.rs discussion on yesterday's entry looking back at DTrace from an eBPF world, jmtd noticed that there was no mention of SystemTap in my entry. SystemTap (also) was once the promising rough Linux equivalent of DTrace, but it's fallen out of favour. I used SystemTap a very little bit back when it was new (for example, to trace the system calls of a setuid program) but did nothing with it since then.
As a sysadmin, I felt that SystemTap had two or perhaps three significant issues. The lesser and questionable issue was that SystemTap was hard to get started with; getting all of the packages on to your system was a little bit intricate in the beginning and the documentation was discouragingly spotty both initially and somewhat later on when I tried it again in 2013. The big issues were that SystemTap was quite slow to start doing things and worked by the scary method of building and loading a new Linux kernel module into the kernel; I believe the kernel module then live-patched the running kernel code on the fly at least some of the time.
These two issues were interrelated; SystemTap was slow because it had to do a great deal of work to create and load that kernel module, and part of why it had to be slow was that a loadable kernel module is very dangerous, and SystemTap was trying to do it without blowing up your system. Because SystemTap used loadable kernel modules, any bugs in its runtime or how it translated your SystemTap script to kernel code could potentially crash your system, which was a scary thing to have to worry about on a production system. The very last thing you want to risk with an instrumentation system is that it makes your problems worse.
All of this effectively made SystemTap a last ditch option for us, something that we would have turned to only if a problem got really bad and it was worth risking crashing a production server in an attempt to diagnose it. In practice our problems never got that bad; we were always able to deal with them in less risky ways.
My perception of eBPF so far is that it is far more stable and officially supported. What eBPF can do is deliberately limited, as compared to the unlimited power of a loadable kernel module, and the core kernel itself works to make eBPF limited and safe. This includes otherwise potentially risky things like hooking into kernel functions with kprobes. This limited power and limited capability for damage makes me much more willing to use eBPF on production systems (once it gets fully available, which is not before Ubuntu 20.04 at the earliest for us). We'll have to test it, of course, but I consider eBPF to be much more intrinsically safe than a loadable kernel module that is supposed to not have any bugs.
(eBPF has had security bugs, which is why we've turned off user access to it, but I don't think it's had many stability issues. Partly I believe this is because its safety gets a lot of attention, since it's part of the core kernel and increasingly heavily used.)