Wandering Thoughts archives

2020-04-27

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.

GoVersionsMyView written at 22:47:42; Add Comment

2020-04-17

Some bits of grep usage are where I disagree with Shellcheck

I have come to very much like shellcheck and now automatically use it on any shell script I'm writing or revising (at least any scripts for work; personal ones I'm sometimes lazier with). Although some of its issues are a little bit picky, using it is good for me so I go along with them. Well, with one exception, because I cannot go along with Shellcheck's views on using egrep and fgrep.

If you've used Shellcheck on scripts, especially older ones, you have probably run into SC2196 and SC2197:

egrep is non-standard and deprecated. Use grep -E instead.
fgrep is non-standard and deprecated. Use grep -F instead.

Sorry, nope. Both egrep and fgrep are long standing programs and names for these versions of grep, and they will be present on any sane Unix until the end of time (and I don't mean 2038, the end of the 32-bit Unix epoch). I have a visceral and probably irrational reaction to the idea of using the POSIXism of 'grep -E' and 'grep -F' for them, and I have no intention of switching my scripts away from using fgrep and egrep.

(And grep already has enough flags to keep track of, including important ones for searching test files in GNU Grep.)

Fortunately modern versions of Shellcheck (including the one in Ubuntu 18.04) can disable these warnings for your entire script, as covered in the wiki's page on ignoring errors. Just put a line in the comment at the start of your script to turn them off:

#!/bin/sh
[...]
# Disable warnings about use of egrep and fgrep
# shellcheck disable=SC2196,SC2197

(I don't want to use a $HOME/.shellcheckrc for this, because I want our scripts to Shellcheck cleanly regardless of who runs Shellcheck.)

ShellcheckAndGrep written at 00:48:05; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.