[emmanueloga_]

For those using Go for production, do you get to switch to the latest versions quickly, or do you get stuck in older releases?

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" :-/).

[zellyn]

At Square, we typically wait until the first point release before updating the default version in our Go monorepo. Individual application owners are free to upgrade sooner. This time, we had some wiggles, so the Go team beat us to 1.22 before we could upgrade our default to 1.21 :-)

Waiting is more or less just customary at this point; Go releases seldom break things.

[zellyn]

Benjamin Wester (whom I just found out reads this and saw my comment, so now I don't feel weird randomly mentioning by name!) is the true hero of our monorepo's upgrades.

[peter_l_downs]

We usually wait to experiment with new features until we find a good problem that would fit, but we upgrade compiler version pretty much right after they release. For instance we waited on actually using generics for about 6 months until we were able to experiment a bit and make sure they were really useful, the devx was good, and build/test speeds weren't significantly impacted.

[adtac]

> build/test speeds weren't significantly impacted

it must be getting a little repetitive to test every version and find that Go continues to build crazy fast every time :)

[AdamJacobMuller]

I remember early in the go release cycle (talking around go1.4->later era) when I would rebuild our application with a new version and marvel at how much faster they made it. GC was another thing which was crazy, they halved GC pause time for like 5 or 6 releases in a row. like 1s -> 500ms -> 250ms -> 125ms etc etc etc.

[peter_l_downs]

The test doesn't take much time :)

[mappu]

At my $DAYJOB devs are free to jump on latest builds for containers we operate (SaaS / API services).

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.

[drchase]

Which older OSes? The last 1.20 dot release was earlier today, some years from now it will be stale and probably insecure, though that matters less for internal apps than for internet-exposed ones.

[mappu]

Windows 7, Server 2012, macOS 10.13 + 10.14, and so on. Together it makes up nearly 10% of our user base.

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!

[signal11]

I thought the 1.21 cuts were for out of support Windows versions only? Eg Windows 7.

You’ll have to also factor that 1.20 won’t receive security updates any more.

[mappu]

Server 2012 was dropped in https://github.com/golang/go/issues/57004 and it's still in security support. My numbers are somewhat similar to @olivielpeau in that thread.

[kromem]

Our CI builds and tests using the 'latest' container for Go, and we have a fairly robust test suite so it essentially auto-updates as things go and breaks the pipeline if anything doesn't work, at which time we either decide to pin the latest working version while we update or hold off on the update to fix breaking changes.

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.

[mortallywounded]

I switch right away.

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{}

[maccard]

We try to keep up to date. We'll be on 1.22 by the end of the month, give or take (all going well)

[catherinecodes]

At work, we upgrade when there's a compelling reason (structured logging in 1.21 came close; we haven't finished migrating from our old logger yet). Before deploying that version, we typically bump versions in all our Go repos and run the tests in those repos. Having the same version across apps gives some people on our team a bit of comfort (with Go, it's not as important as some other runtimes).

[voidfunc]

Usually we switch after the first point release.

[didip]

I switched right away. All of our images are tagged anyway so rolling back is hella easy.

[miki123211]

I don't think this is necessarily true, most of the standard library docs have switched over to using any, even when generics are not involved.

[dharmab]

Upgrade our binaries immediately, then bump go.mod `go` directive as we touch things.