Live data from Hacker News

Go 1.27

go.dev

41–50 of 277 posts

Re: Go 1.27

#42
post #35

Brace for a wave of drive-by pull-requests swapping google/uuid [1] out for the now-standard uuid package [2]. Kubernetes project will be the first one [3] I guarantee it. [1] https://pkg.go.dev/github.com/google/uuid [2] https://go.dev/pkg/uuid [3] https://github.com/kubernetes/kubernetes/blob/2220c3853a2402... [4] https://github.com/google/uuid/issues/221

Unfortunately for people SELECTing UUIDs out of a DB directly into a uuid struct, the built-in uuid structs don't implement the necessary interface for that, so you'll have to continue using the google package, or a plain string.

Or just a number (128-bit).

Re: Go 1.27

#44

This makes me want to find a side project for an excuse to give Go another try (I last used it professionally pre-generics). I do still wish it had discriminated unions (algebraic data types) and some better error handling ergonomics.

Do it. It is just a beautiful language to write and much simpler to pickup than many others. I am a fan boy of course but I love Go.

Go is extremely easy to pickup. If you know any language you probably know Go already for the most part (channels notwithstanding).

I wouldn't say it is a "beautiful" language however. Though that is in the eye of the beholder, I don't think the Go designers were even really going for beauty.

Re: Go 1.27

#45

Wait generics? What changed? Why is golang accepting of generics now?

There are some details here about the history of how generics finally came to Go: https://golang.design/under-the-hood/en/part2lang/ch08generi...

The tl;dr boils down to a combination of valuing both compilation speed and execution speed.

Re: Go 1.27

#47

Earlier quoted context omitted.

Do it. It is just a beautiful language to write and much simpler to pickup than many others. I am a fan boy of course but I love Go.

Go is extremely easy to pickup. If you know any language you probably know Go already for the most part (channels notwithstanding). I wouldn't say it is a "beautiful" language however. Though that is in the eye of the beholder, I don't think the Go designers were even really going for beauty.

They were going for readability. You can make some impossible to read code with C++ because the programmer was too clever, and the designers of golang wanted to avoid that.

Re: Go 1.27

#48
post #35

Brace for a wave of drive-by pull-requests swapping google/uuid [1] out for the now-standard uuid package [2]. Kubernetes project will be the first one [3] I guarantee it. [1] https://pkg.go.dev/github.com/google/uuid [2] https://go.dev/pkg/uuid [3] https://github.com/kubernetes/kubernetes/blob/2220c3853a2402... [4] https://github.com/google/uuid/issues/221

Unfortunately for people SELECTing UUIDs out of a DB directly into a uuid struct, the built-in uuid structs don't implement the necessary interface for that, so you'll have to continue using the google package, or a plain string.

The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs.

[1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...

Re: Go 1.27

#49
post #31

Not mentioned: Floating-point parsing and formatting now uses Russ Cox's uscale algorithm. https://research.swtch.com/fp https://github.com/golang/go/blob/go1.27.0/src/internal/strc...

I’m so happy Russ still contributes even though he isn’t lead anymore. I always enjoy reading his blog posts
Post reply on HN