Comment by ashirviskas
2 days ago
As a non go developer, may I ask why you're using older go version 1.21? Is there a reason to stay with older releases?
EDIT: It seems like it was deprecated 10 months ago
2 days ago
As a non go developer, may I ask why you're using older go version 1.21? Is there a reason to stay with older releases?
EDIT: It seems like it was deprecated 10 months ago
Windows 7 support is one reason to stick to older GoLang releases. A project in Go 1.21.4 or earlier will work on every Windows release and any computer made since 2009, whereas a version bump to v1.21.5 means it will only work on more recent computers and Win10 and 11 for no benefit.
https://github.com/golang/go/issues/64622
I think this is a reasonable take. Yes, people shouldn't be running Windows 7 as their daily driver. But if you can support it at basically no effort and without sacrifices that is the right thing to do. Supporting more platforms is a good thing, even if that platform is an old Windows version instead of an Amiga
> and without sacrifices
There are always trade-offs/sacrifices.
The Go team isn't making new versions just for fun. Each version since 1.21 has had improvements. Especially the fix/change to for loop variables in 1.22 is very nice to have, and helps preventing to write bugs.
If there's a reasonable expectation that users will use outdated platforms, it makes sense to support them. If there is no such expectation at all, why would one forego the improvements to the language and tooling.
There's always a price to pay.
1 reply →
The README is likely AI-generated. The actual go.mod file lists 1.23.1 as the Go version[1], which implies a requirement of Go 1.23.1 or higher[2].
[1] https://github.com/piyushgupta53/go-torrent-client/blob/6130...
[2] https://go.dev/doc/modules/gomod-ref#go-notes
Go 1.21 includes an internal auto-updater that can compile later Go versions by looking in the go mod file itself.
So the README is correct.
Automatic toolchain switching does not trigger compilation of later Go toolchains; it only attempts fetching a blob (if available) and using that to perform builds[1]. If a system supports Go 1.21 but not 1.23.1 (e.g. Windows 7, mentioned in a sibling comment), then this project will fail to build on said system. Likewise, if a user on Go 1.21 has disabled automatic toolchain switching, the Go CLI refuses to build the project at all.
Overall, I would say the minimum required Go version is indeed the Go version declared in the go.mod, since that is the declared minimum required toolchain.
[1] https://go.dev/doc/toolchain#select