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.
I love how proactive the crypto team is about post quantum. They released https://pkg.go.dev/crypto/mldsa. The lead maintainer Filippo Valsorda wrote a nice piece here[1] to urge the tech world to start deploying good enough versions of post quantum crypto.
While I'm highly sympathetic to competing priorities crowding out movement to pq cryptography. At the same time it's not sudden at all. It's been 10 years since nist first said "move shit over"?
> First, generic methods are now supported
> Generic functions can now be used without explicit type arguments
Great! This was an ergonomic code issue I hit when trying to create a universal handler/controller generic that could hydrate/populate function arguments (from a request body) without having an actual copy of the arguments: https://github.com/xeoncross/mid/blob/main/handler.go#L12
> Second, a key in a struct literal may now be any valid field selector for the struct type, allowing fields in nested or embedded structs to be initialized directly
It's been a while since I've written more than anything trivial in golang, but this seems like a big deal to me. As in, I can define a struct that is consistent and reusable in other structs
You might want to follow this proposal, if you aren't already. It's the most recent one, and it's supported by quite a few “core members” of the Go Team. I don't think it'll land in 1.28, but I like the fact that it's still a feature that's being actively discussed.
This is only a small piece of the story for what people say when they want tagged unions. Without all of the ancillary support in the language, like exhaustive pattern matching, it really doesn't count.
That is a LOT of code (very ugly code, I would add) that could be replaced by `type Float = float32 | float64` in a language with actual support for union types.
I'm so glad the new uuid package landed - it's overdue but a very welcome addition! I've already replaced github.com/google/uuid with `uuid` in several projects
I like to imagine that one day we'll have a language that launched with all the features languages eventually add. The whole ecosystem of packages would be built on them instead of a legacy of more primitive language feature sets.
I mean one thing frontier models are really good at is porting code with pretty low level of supervision. Provided there are enough fans porting packages from other ecosystems should not be a big challenge.
I love Go because even minor versions deliver great value like this. The struct literal inits and generic methods are great conveniences to clean up clumsy boilerplate.
Not to mention it’s just a dream language to work with , especially when building concurrent applications. I love engaging all of my cores. And memory is so expensive nowadays
Minor versions are basically major versions for Go. They’ll “never” create a Go v2 because they prioritise maintaining backwards compatibility as a language feature, thus following semver rules, no majors.
Being on the HN's homepage isn't as simple as "most upvoted articles in last X hours". They take into account upvote velocity: 40 upvotes in 40 minutes isn't the same as 40 upvotes in 4 yours.
Would you rather have yet another LLM-generated slop article in its place instead of an article covering a major release for a widely-used language? Out of all the articles that reach the HN front page, this is the one you have a problem with?
Wasn't Go supposed to be "simple"? I remember how Go advocates used to boast about not having generics and now it almost seems like Go is trying to become some sort of C# or Java Frankenstein. I'm not even trying to badmouth Golang - just legitimately confused.
https://research.swtch.com/fp
https://github.com/golang/go/blob/go1.27.0/src/internal/strc...
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
[1] https://words.filippo.io/crqc-timeline/
Great! This was an ergonomic code issue I hit when trying to create a universal handler/controller generic that could hydrate/populate function arguments (from a request body) without having an actual copy of the arguments: https://github.com/xeoncross/mid/blob/main/handler.go#L12
It's been a while since I've written more than anything trivial in golang, but this seems like a big deal to me. As in, I can define a struct that is consistent and reusable in other structs
I do still wish it had discriminated unions (algebraic data types) and some better error handling ergonomics.
https://github.com/golang/go/issues/76920
You might want to follow this proposal, if you aren't already. It's the most recent one, and it's supported by quite a few “core members” of the Go Team. I don't think it'll land in 1.28, but I like the fact that it's still a feature that's being actively discussed.
https://github.com/splizard/tagged
I like to imagine that one day we'll have a language that launched with all the features languages eventually add. The whole ecosystem of packages would be built on them instead of a legacy of more primitive language feature sets.
Standard ML is a perfect programming language from the 90s. It unfortunately does not have a great eco system of packages.
Sure a SIMD expert writing assembly can probably do a better job than an LLM using these new intrinsics, but it’s still massively faster.
The `go fix` modernisers are also great, have already run them in several repos.
Not to mention it’s just a dream language to work with , especially when building concurrent applications. I love engaging all of my cores. And memory is so expensive nowadays
It sounds like the dumbest thing in the world, but I love the import system auto-adding stuff inside of vscode when I need it. just slick.