Also, there was some discussion in the previous thread that it’s bad to force users to upgrade to a recent version of Go. However, I think it is good to encourage users to be on a supported version of Go. Since the previous two minors are supported and releases are roughly 6 months apart, that suggests an upgrade is required every ~18 months. There’s no compelling reason to change the go.mod declaration to something recent by default (except that you seemingly can’t change it in the online editor), but I think the test runner should support recent versions if users want to use newer features.
I’m not actively maintaining the Go track anymore, but I’ll try to find some time this week to take a look at this (no promises though).
I’m thinking on having the tooling backend running and accepting Go 1.25.
Support for a language is always tricky to define. Go officially supports the 2 last minor versions, including the most recent one and that means an upgrade every year at least.
However, if we consider some group of users, say the Ubuntu users, they might be in a recent LTS and still have the default Go version that is packaged in their distribution be > 1 year old. We are telling those users they should not install Go from their distribution directly and choose another installation method.
We often see that supported linux distributions are packaging unsupported versions of Go by default, which muddies the discussion on which version we should support.
Actually, there is. The new versions are introducing a lot of new language features. And since Go 1.21, the version in the go directive of the go.mod file, does declare a minimum version, which affects the languages features that are available at compilation time.
For instance, if one makes a program that uses range over iterators using a Go 1.25 compiler, everything works fine if your go.mod declares Go >= 1.23, which is the language version where the feature was introduced. But as soon as you declare a version in your go.mod lower than 1.23, the program refuses to compile, even though you might be using Go 1.25 to compile it:
$ go version
go version go1.25.1 windows/amd64
$ cat go.mod
module gofeatures
go 1.18
$ go build
# gofeatures
.\main.go:58:17: cannot range over lst.All() (value of func type iter.Seq[int]): requires go1.23 or later (-lang was set to go1.18; check go.mod)
.\main.go:65:17: cannot range over genFib() (value of func type iter.Seq[int]): requires go1.23 or later (-lang was set to go1.18; check go.mod)
So, increasing the go version in the go.mod file enables access to new language features. And given the number of language features introduced since the current version in the go.mod (1.18) of the exercises, it’s time we update this.
I think having the go.mod files at Go 1.23 is probably good, as it’s the version Go stopped having new language features and it’s a relatively recent version.
Still some work to do, but the core of the upgrade went smoothly. Go had a few formatting changes on the test error messages the go test command produces, which required some test adjustments.