Live data from Hacker News

Go 1.22

go.dev

21–30 of 164 posts

Re: Go 1.22

#21
post #13

Earlier quoted context omitted.

for i := range 10 { What was the syntax for this before?

for i := 0; i

I must be getting old because I almost wish they didn't add this as it's slightly ambiguous whether it's ranging from [0, 10) or [1, 10] and anything ambiguous is probably going to haunt me at 3am some day

Re: Go 1.22

#22

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

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

Re: Go 1.22

#23
post #21
post #13

Earlier quoted context omitted.

for i := 0; i

I must be getting old because I almost wish they didn't add this as it's slightly ambiguous whether it's ranging from [0, 10) or [1, 10] and anything ambiguous is probably going to haunt me at 3am some day

I always just assume it is consistent to whether arrays start at [0] or [1] on whichever language I am working on.

Re: Go 1.22

#24

The addition of `sql.Null[T]` is great. I'll probably start using that in new projects. In current stuff, I'm relying on sqlboiler's null [0] whose API is very similar — it works the same way as `sql.Null` will, but has an additional `IsSet() bool` method that tells you whether or not the value was ever explicitly set, to help you distinguish "intentionally null" from "null due to uninitialization". (Sounds nice, but…

Curious when you need to know when null is intentional or not. There's no corresponding type like that in the db.

Re: Go 1.22

#25

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

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.

Re: Go 1.22

#26

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

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

Re: Go 1.22

#27
> When io.Copy copies from a TCPConn to a UnixConn, it will now use Linux's splice(2) system call if possible, using the new method TCPConn.WriteTo.

Interface upgrades, yet again, transparently giving us more zero-copy IO. Love how much mileage they’re able to get out of this pattern in the io package.

Re: Go 1.22

#28
post #6

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

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.

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.

Re: Go 1.22

#29
post #18

Earlier quoted context omitted.

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.

> 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 :)

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.

Re: Go 1.22

#30
post #21
post #13

Earlier quoted context omitted.

for i := 0; i

I must be getting old because I almost wish they didn't add this as it's slightly ambiguous whether it's ranging from [0, 10) or [1, 10] and anything ambiguous is probably going to haunt me at 3am some day

Interestingly, this does not raise any error, rather has no effect.

for i := range -10 { panic(i) }

Post reply on HN