Live data from Hacker News

Stop picking my Go version for me

blog.howardjohn.info

11–20 of 64 posts

Re: Stop picking my Go version for me

#12
> 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.

Re: Stop picking my Go version for me

#13

How your go.mod should look: go 1.24.0 toolchain go1.25.7 "This module compiles with the language and runtime of go 1.24 and later, but I recommend you use at least go release 1.25.7" go get can manage this for you - https://go.dev/doc/toolchain#get

this is great and should be in the blog post

Re: Stop picking my Go version for me

#14
post #6

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

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.

Re: Stop picking my Go version for me

#15

>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…

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.

Re: Stop picking my Go version for me

#16

>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.

Re: Stop picking my Go version for me

#17
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.

Re: Stop picking my Go version for me

#19
post #6

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

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.

Re: Stop picking my Go version for me

#20
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.

Post reply on HN