Go 1.27

371

ddatabase64128 about 4 hours ago 81 commentsRead Article on go.dev

ES version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

83% Positive

Analyzed from 1707 words in the discussion.

Discussion (81 Comments)Read Original on HackerNews

e4m2•about 3 hours ago

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•about 2 hours ago

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

dvt•about 2 hours ago

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.

teabee89•about 3 hours ago

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•about 3 hours ago

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•about 3 hours ago

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

halJordan•about 1 hour ago

Ah. This is a bold faced lie. There were plenty of options in 2016. Nist released final candidates in 2024 and published the candidates this year.

ssh (as noted in tfa) has had pq defaults since 2022.

eterm•about 1 hour ago

The .NET team have been similarly busy on post-quantum lately, it completely dominated the .NET API reviews for the dotnet 11 release.

It seems there's a big push happening behind the scenes.

stackskipton•39 minutes ago

US Government is starting to push hard so code first needs to support it.

amelius•43 minutes ago

Ok, but when is it coming to our web browsers and email clients?

Retr0id•20 minutes ago

I don't know about mail clients, but it's in most web browsers already.

guessmyname•about 3 hours ago

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•about 3 hours ago

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•about 2 hours ago

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

deepsun•about 2 hours ago

Or just a number (128-bit).

reactordev•about 2 hours ago

Oooof… well played go team, well played.

dabber21•about 3 hours ago

will 'go fix' take care of this?

Xeoncross•about 3 hours ago

> 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•about 3 hours ago

Neat, stealing this.

Xeoncross•15 minutes ago

I wrote a blog on it if you're interested: https://xeoncross.com/2026/better_go_handlers.html

xavdid•about 1 hour ago

I love these release notes but I really wish they would add syntax highlighting to the Go blog. I'm always a little bit surprised/disappointed whenever I land on a go.dev link since I know the code will be just a little harder to visually parse than it needs to be.

treyd•about 1 hour ago

There's a reason for this. Rob Pike was asked about it and said that syntax highlighting reminds him of the bright colors of children's toys and he personally disables it so that he can focus on the text.

I don't know why it's still like that but that's the original reasoning.

tester457•about 1 hour ago

> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals.

https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...

IshKebab•about 1 hour ago

That must be why traffic lights and electrical wires and transit maps are all black and white...

xavdid•about 1 hour ago

That makes sense as a personal preference for him, but it's odd for that to still be the company/project stance. Like, surely he knows he's the minority for not wanting highlighting?

mparnisari•about 1 hour ago

that's an extremely odd explanation and it makes me think that he has some hidden PTSD. it's also insane that one person's preference trumps the rest of the world's.

pigeonhole123•about 1 hour ago

He also doesn't capitalize his sentences.

zanderwohl•about 1 hour ago

Welcome to Go as a project.

parsd•29 minutes ago

I understand and respect this position. I think syntax highlighting is a highly subjective matter, bordering on personal preference with regard to shell interactions, editor configurations, bindings, shortcuts, snippets, and the like. It's also... insignificant somehow, like quibbles over formatting rules that Go settled once and for all with `go fmt`.

I often prefer not to enable syntax highlighting just for color. Occasionally I'd choose some minimal theme that only highlights string literals and keywords. So it has two or three colors. But some of the color schemes I see are a festival of lights where every special element of syntax has its own color. I don't understand how that is supposed to help me parse anything and why the rules are complex. The `range` keyword needs to be purple, and `chan` must be navy blue. Why exactly? And every site has a different color scheme? There is no consensus, and there shouldn't be.

For a serious community-driven project like Go, dealing with the question of syntax highlighting is strange. The creators deliberately avoided the questions of IDEs and editors for Go, leaving them to the community. I think the same principle applies here.

ClikeX•about 1 hour ago

I just have a tampermonkey profile for go.dev to fix that for me.

olingern•about 4 hours ago

> 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

andreimackenzie•about 1 hour ago

This will shorten many test files!

konart•about 3 hours ago

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

onionisafruit•about 1 hour ago

It will be very nice working with code generators like oapi-codegen that can generate either nested structs or very unwieldy struct names. So big in that context, but like you said just a nice qol improvement most of the time.

piinbinary•about 4 hours ago

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•about 4 hours ago

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•about 3 hours ago

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

https://github.com/splizard/tagged

mirashii•about 3 hours ago

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•about 2 hours ago

You can also add support for exhaustive switches on tags.

shhsshs•about 3 hours ago

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•about 2 hours ago

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

kccqzy•about 2 hours ago

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.

codegeek•about 3 hours ago

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•about 2 hours ago

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•about 2 hours ago

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•about 3 hours ago

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•about 2 hours ago

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.4GHz in Go, which I think is really impressive.

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

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

patabyte•about 4 hours ago

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

sethops1•about 4 hours ago

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

adonovan•10 minutes ago

Broken how? Please report an issue. The latest gopls should support generic methods.

atsjie•about 3 hours ago

Thank you for the headsup!

ejboy•35 minutes ago

Used to code primarily in Java. Now my app stack is about 80% Go. I love that it enables lightweight application development. Glad to see the platform evolving with a focus on resource efficiency.

nick_•about 4 hours ago

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•about 3 hours ago

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•about 3 hours ago

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•about 4 hours ago

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

ejboy•33 minutes ago

Keeping priorities right!

olexsmir•about 3 hours ago

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

tschellenbach•about 4 hours ago

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

jeanbza•about 4 hours ago

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•about 3 hours ago

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•about 3 hours ago

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•about 2 hours ago

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•about 3 hours ago

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•about 2 hours ago

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

amelius•about 1 hour ago

Python is already the language everyone needs.

dude250711•about 1 hour ago

Quarterly reminder that Go still exists.

IshKebab•43 minutes ago

I can imagine using it for simple web stuff. E.g. its perfect for something like Forgejo. But yeah... Seems like the world has moved on mostly.

aliasxneo•23 minutes ago

A large portion of the DevOps/Platform Engineering world uses Go.

SpaceManNabs•about 2 hours ago

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

a2ff6eeb0•about 2 hours ago

They landed half a decade ago...

nrr•about 2 hours ago

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•about 2 hours ago

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•about 2 hours ago

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