Remix.run Logo
Go 1.27(go.dev)
303 points by database64128 3 hours ago | 49 comments
e4m2 an hour ago | parent | next [-]

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...

jeremyloy_wt an hour ago | parent [-]

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

dvt 19 minutes ago | parent [-]

One of my engineering highlights was Russ reviewing a few of my contributions to Golang (to the core http library). He's a super cool and nice guy. I don't really write that much Go anymore, but it was a fun & cute language when it first came out.

guessmyname 2 hours ago | parent | prev | next [-]

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

iaaan an hour ago | parent | next [-]

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.

agwa an hour ago | parent | next [-]

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/...

reactordev an hour ago | parent | prev | next [-]

Oooof… well played go team, well played.

deepsun an hour ago | parent | prev [-]

Or just a number (128-bit).

dabber21 an hour ago | parent | prev [-]

will 'go fix' take care of this?

teabee89 2 hours ago | parent | prev | next [-]

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.

[1] https://words.filippo.io/crqc-timeline/

halJordan 2 hours ago | parent [-]

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"?

Valodim an hour ago | parent [-]

Yes, and at that time the answer was "move over where?" now it's 2026 and x-wing is a draft still

Xeoncross 2 hours ago | parent | prev | next [-]

> 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

iaaan an hour ago | parent [-]

Neat, stealing this.

olingern 2 hours ago | parent | prev | next [-]

> 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

konart 2 hours ago | parent [-]

This is quite a QoL issue, but is it big? Nothing changes from functional point of view.

piinbinary 2 hours ago | parent | prev | next [-]

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.

ainar-g 2 hours ago | parent | next [-]

Re unions:

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.

Splizard 2 hours ago | parent | prev | next [-]

Tagged unions can be implemented in user code, you dont actually need language support to use them.

https://github.com/splizard/tagged

kccqzy 12 minutes ago | parent | next [-]

The C++ committee said the same thing, and gave us std::variant. They are painful to work with and do not really deliver most of the benefits people want.

mirashii an hour ago | parent | prev | next [-]

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.

Splizard an hour ago | parent [-]

You can also add support for exhaustive switches on tags.

shhsshs an hour ago | parent | prev [-]

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.

kccqzy 11 minutes ago | parent [-]

Tagged unions are not union types. A union type is a supertype for any arbitrary collection of types, but a tagged union is a single type with multiple data constructors, and does not require subtyping to be implemented.

codegeek 2 hours ago | parent | prev [-]

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.

osigurdson an hour ago | parent [-]

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.

fragmede an hour ago | parent [-]

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.

tyho an hour ago | parent | prev | next [-]

The SIMD stuff is incredible. I have been having lots of fun with it. You can use LLMs as a scalar to SIMD transpiler, it works amazingly well.

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.

nkanaev 38 minutes ago | parent [-]

Agreed. I've recently translated a pangram generator project written in Rust [1] leveraging SIMD to do the same in Go [2] to see how it fairs in terms of speed - the results are pretty close. In my local machine I'm getting ~3GHz in Rust vs ~2.5GHz in Go, which I think is really impressive.

[1]: https://github.com/tuzz/pangram-machine

[2]: https://github.com/nkanaev/pangram-machine-go

sethops1 2 hours ago | parent | prev | next [-]

FYI golangci-lint and gopls are both broken if you try using generic methods.

atsjie 2 hours ago | parent [-]

Thank you for the headsup!

patabyte 2 hours ago | parent | prev | next [-]

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

nick_ 2 hours ago | parent | prev | next [-]

Nice additions to go.

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.

fmbb 2 hours ago | parent [-]

I don’t think launching Go today would have been better than 15 years ago.

Standard ML is a perfect programming language from the 90s. It unfortunately does not have a great eco system of packages.

qaq an hour ago | parent [-]

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.

tschellenbach 2 hours ago | parent | prev | next [-]

Every release CPU load becomes a bit lower. Love it :)

tschellenbach 2 hours ago | parent | prev | next [-]

New JSON is amazing, and SIMD will be big for json, audio/video etc.

olexsmir 2 hours ago | parent | prev | next [-]

Full release notes: https://go.dev/doc/go1.27

jeanbza 2 hours ago | parent | prev | next [-]

I have been waiting for generic methods and can't wait to use them!

The `go fix` modernisers are also great, have already run them in several repos.

tonymet 2 hours ago | parent | prev | next [-]

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

radicalriddler 2 hours ago | parent [-]

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.

tonymet 37 minutes ago | parent [-]

true that, but we get a couple of these a year it seems, so their overall velocity is excellent, and without breaking anything. a dream language.

Hasz 2 hours ago | parent | prev | next [-]

I have recently been spending time learning go, really really liking the language, awesome standard lib, excellent tooling and great experience.

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.

kar1181 39 minutes ago | parent | prev | next [-]

Go - the language no one likes, but frankly everyone needs.

SpaceManNabs an hour ago | parent | prev | next [-]

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

a2ff6eeb0 an hour ago | parent | next [-]

They landed half a decade ago...

nrr an hour ago | parent | prev [-]

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.

pregnenolone an hour ago | parent | prev [-]

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.

kermatt 25 minutes ago | parent [-]

A problem was so many others were screaming about the lack of generics, as though there were not other language options that provided them.