August 20th, 2024

Go automatically downloads a newer toolchain if needed

Go now automatically downloads newer toolchains from version 1.21, allowing users to manage toolchain versions via the GOTOOLCHAIN variable, with security measures in place to ensure safe downloads.

Read original articleLink Icon
Go automatically downloads a newer toolchain if needed

Go has introduced a feature that automatically downloads a newer toolchain if needed, starting from version 1.21. This functionality allows the Go command to utilize its bundled toolchain or download other versions as required. The toolchain will be downloaded when the Go version specified in the go.mod file exceeds the current Go binary version, provided the binary is at least version 1.21. Users can specify a particular toolchain using the GOTOOLCHAIN environment variable, with options for auto, local, and path settings. The downloaded toolchains are stored in the GOPATH under the golang.org/toolchain module. This feature simplifies the setup process for Go projects, ensuring that as long as a reasonably up-to-date Go binary is available, users can easily bootstrap their projects. While there are concerns about downloading binaries from the internet, the security measures in place, such as module checksums, help mitigate risks. Users who prefer not to use this automatic downloading feature can disable it by setting GOTOOLCHAIN to local, which is also recommended for continuous integration environments to maintain version consistency.

- Go now automatically downloads newer toolchains starting from version 1.21.

- Toolchains are downloaded when the specified version in go.mod exceeds the current binary version.

- Users can control toolchain behavior using the GOTOOLCHAIN environment variable.

- Downloaded toolchains are stored in the GOPATH under the golang.org/toolchain module.

- Security measures, including module checksums, help ensure safe downloads.

Link Icon 13 comments
By @matthartstonge - about 2 months
Yeeeah, this made me lose half a day learning about and then unwinding “toolchain” being accidentally set across all our microservices…

Made a little harder to track down initially as we have a replace directive pointing to a local proto module in each service. It was here that toolchain was set which forced it to keep appearing in the top level module.

Should’ve been opt in behaviour by default not enforced.

We’ve decided to sit on n-1 of Go and I’ve already had an example last month of a well used OSS library setting toolchain to 1.22 as a patch release (which could be considered a breaking change) which fortunately was quickly reverted.

By @devsda - about 2 months
Link to the proposal behind this change:

https://go.googlesource.com/proposal/+/master/design/57001-g...

> Many people believe the go line in the go.mod file specifies which Go toolchain to use. This proposal would correct this widely held misunderstanding by making it reality.

That doesn't sound like a good reason to automatically download binaries and run them.

Is it difficult to update or install a new version of Go and are there frequent updates in Go spec introducing new features that it is necessary to auto install the compiler itself ?

Supply chain attacks are on rise and not a new concept and yet we see these changes.

This is not the first time Go lang has introduced a questionable opt-out feature [1]. They backed out but looks like there were no takeaways from that episode.

1. https://news.ycombinator.com/item?id=34771472

By @poincaredisk - about 2 months
I'm not sure I like this feature. I prefer to be in control of the software that runs on my system, without any automated downloads. But I'm a nixos user so...
By @mseepgood - about 2 months
The way to look at it: The Go toolchain is just another dependency to your project, declared in go.mod, just like the other modules, and handled accordingly (download, verification etc.)
By @anotherhue - about 2 months
Best worst thing about nixos is that none of these terrifying tricks work because the binaries can never find libc.
By @sestep - about 2 months
If I understand correctly, Rust acts similarly: if you have a `rust-toolchain.toml` file in your repo, any usages of `cargo` will automatically install and use that version of Rust. https://rust-lang.github.io/rustup/overrides.html
By @kchr - about 2 months
I can see the appeal, but hope they keep it opt-in so that people can choose their preferred workflow without surprises.
By @pjmlp - about 2 months
> By the way, this only works well because Go binaries are static, one of the things that make the language reasonable good.

Only by default, as the Go toolchain supports dynamic linking for ages, and without third party dependencies called via cgo, or stuff like DNS resolution on Linux.

By @seneca - about 2 months
I'm broadly a Go fan, but this strikes me as a terrible decision. Critical tools should not be working through magic like this. Just fail with a clear error and let the user fix it as they see fit.

If they want magic like this, it should be opt-in, not opt-out.

By @Sphax - about 2 months
I like this feature, I used this to be able to use iterators before Go was updated in Homebrew.

And yes you need to make sure GOTOOLCHAIN=auto, my colleague had to explicitly set it because it defaults to local on Gentoo.

By @tapirl - about 2 months
GoTV does similar things but plays it explicitly: https://go101.org/apps-and-libs/gotv.html

GoTV builds needed toolchain versions with the Go source code instead of downloading the pre-built toolchain packages.

By @igtztorrero - about 2 months
It should be optional to activate this feature.
By @Jyaif - about 2 months
This sounds amazingly convenient! Language creators, please take note.