Stop picking my Go version for me
blog.howardjohn.info36 points by ingve 6 hours ago
36 points by ingve 6 hours ago
>My package really does depend on the latest patch release!
> Even in the event that your packages code is only correct with a specific patch release, I still think its wrong to put that version in the go directive unless it cannot be compiled with any other version.
I'm not a go user, but this strikes me as an over-reaction. If your code is only correct with a specific patch release, then it really is your business to make that so. If someone downstream wants to use library_method_broadly_correct and not library_method_correct_only_with_latest, then downstream should patch your source to allow them to do something unsupported. That becomes their problem. If this is likely to be a significant problem that will affect many users, then this is a codesmell warning you that you've probably got two libraries which you're just jumbling together into one: the solution isn't to falsely gate a safe function behind a high dependency version, nor to falsely release a function to people who can't use it safely, but to publish each with its own requirements expressly stated.
That part struck me as well. I agree with the premise that the field should represent the minimum supported version, but I don’t understand the argument that it shouldn’t be set to the minimum supported version that works. That’s the point of a minimum supported version field.
I can admit that part was maybe a bit extreme :) fortunately in practice this would be a pretty rare situation IME due to how compatible Go is across versions.
(Blog author)
How your go.mod should look:
go 1.24.0
toolchain go1.25.7
go get can manage this for you - https://go.dev/doc/toolchain#get
The author fails to mention any of the negative effects they experience due to this go version selection. They say that the effect is "viral" but don't give any concrete examples of why it's a bad thing to keep your toolchain up to date
One of the key advantages of Go is its very compatible, you can compile and run early versioned code on the latest compiler without concern and it will just run with less bugs and faster due to all the advancements over time. I don't like being forced to upgrade my tooling until I choose the upgrade but in Go's case its usually trivial.
Anyone with an older toolchain can’t build that library of anything that depends on it.
Some environments might not even have the newer version available.
Anyone with an older toolchain is free to fork it on github, test with the older version, and CI to the project that tests with the older version, and submit a patch, too!
This may not get the project as many users, but not everyone who writes a 50 line project is trying to figure out which versions it supports and setting up full test matrices either.
I am missing this part too. I can't really say ever having a problem upgrading go to the latest version. Now with "go fix", a lot of features are even improved automatically.
I used to see supporting multiple versions of Python as an expensive chore... and then I learned how to use the GitHub Actions matrix feature and supporting multiple versions is suddenly easy - my test suites are comprehensive enough that if they pass I'm confident it will work on that version.
I expect this should work equally well for Go.
In other ecosystems, I could see how this could be a problem, but I don’t think I’ve ever had a problem with a Go upgrade.
What’re the actual, practical results of a package pushing you towards a higher go version that you wouldn’t otherwise have adopted right away? Why is this actually important to avoid beyond “don’t tell me what to do”?
One potential reason is that Go does drop support for older OSes sometimes. For example, Go 1.22 is the newest version that works with older Mac OSes.
Or, I have only tested my library on this version, and nothing lower.
> Even in the event that your packages code is only correct with a specific patch release, I still think its not always right to put that version in the go directive unless it cannot be compiled with any other version.
This just makes me shiver. Imagine releasing a library with a version number slightly lower because of this post, it compiles, but there is a bug that brings down production...
Thanks but not thanks.
This just got me. Datadog decided that they only support the current and last major versions of Go. So, 1.26 and 1.25. But in my cause we're still on 1.24.13 which was released by the Go team less than two months ago.
Datadog won't be getting a renewal from us.
> The version is the minimum version your project can be compiled with.
Sure. But guess what, virtually nobody is going to find out what that "minimum version" is, and your blog post is not going to change that.
Just install the latest toolchain.
Same situation in Rust crates, AIUI.
In go, `go mod init` and `go get go@latest` (both recommended commands), both set a 'go <latest-version>' stanzas. In go, you _must_ set a minimum required version.
If you type 'cargo init', you will get 'edition = "2024"', but no 'rust-version'.
The situation is different because rust does not require a 'rust-version' in Cargo.toml, and in practice most crates do not have one, while in go it is required you specify a minimum version, there's no automation to set it to the true minimum, and most projects update it incorrectly in practice (because the go cli updates it incorrectly for you).
I think Rust is slightly different in practice even if they behave the same technically. I'm not sure Rust lets you even set the MSRV to a specific patch which is the biggest annoyance with Go; if they do it's so uncommon I've at least never seen it. And I don't believe any Rust tooling encourages you to set the MSRV to <latest Rust version> like tools in the Go ecosystem do.
> Its not your responsibility to ensure transitive importers of your library are on the latest version of Go. Don't make that decision for them.
and yet the Go maintainers did not include or build (in the future) a tool that determined the minimum version of Go that your application can be compiled in.
I always stay up with the latest go releases and if I am touching one of my packages that are set to lower in go.mod, I update it. It is an easy maintenance task to make sure I am keeping up with the latest standard library and tooling changes and improvements.
Weird that this needs to be said. I’m not familiar with the Go ecosystem, but there is usually a natural incentive for library developers to reach more people, which means you’d want to support the oldest feasible version. If you don’t do that then someone will develop a better library which does support an older version. Is that not happening here?
>It is not the version you use to compile your project
But it is the version which they support. Pushing it back to an older version may result in bad behavior even if it does compile.
I think only languages which are still in beta have that kind of back compatibility. If a language breaks compatibility every two years (roughly Debian’s release schedule), it’s a toy, not a tool.