In the open a lot of projects seem to avoid newish features. I like to use `any` (from 1.18 ~ 2 years ago) where before we had to use `interface{}`, even if I'm not using generics (although I've been told the latter is more "idiomatic" :-/).
Waiting is more or less just customary at this point; Go releases seldom break things.
it must be getting a little repetitive to test every version and find that Go continues to build crazy fast every time :)
But we also deliver end-user apps with Go, and those have to stick to 1.20 for compatibility with older client OSes. 1.21 made significant cuts and so we will likely be on 1.20 for some years to come.
We have a very slow-moving customer base and their choice of OS is out of our control. At this time last year there were still more Windows 7 users than Windows 11 in telemetry.
Those old OSes are leaving security support, but actually Windows Server 2012 still gets updates from Microsoft (ESU) until 2026 so i'm surprised you dropped it already.
Yes, Go1.20 will get insecure, but until that usage drops, not much can be done.
Well, one thing: in the past, in order to maintain support for Server 2008, for a long while we built the app with both Go1.10 and Go1.(newer) and switched at install time. I don't recommend it! Every year was more difficult as the open source packages drifted away from compatibility and our build system had to still support GOPATH. Eventually we finally abandoned Go1.10!
You’ll have to also factor that 1.20 won’t receive security updates any more.
Very rarely, like once every few years, there's some subtle edge case bug that shows up with a third party package and the new version, but honestly we'd never catch that if we were manually upgrading anyways, as by definition these bugs avoided our test suite.
If you're worried about supporting older Go compilers, you could always have build conditions for older versions that define missing things like:
// +build !go1.7
type any = interface{}