Notes ·
Go 1.27 Shipped, and Some of the Best Parts Barely Made the Release Notes
Source
Nicholas Husin, on behalf of the Go team
Earlier this month I wrote that Go 1.27 was going to be a big release, based on the draft release notes.
Now it is actually here.
The final release shipped August 19, and surprisingly little changed from what we were expecting. Generic methods made it. encoding/json/v2 made it. The new uuid and crypto/mldsa packages made it. The goroutine-leak profiler, faster small allocations and experimental SIMD support all made it too.
That is reassuring. Go's release candidates tend to be exactly that: candidates for a release that has already been thought through, rather than a place to keep inventing features until the last minute.
One thing the final announcement does not call much attention to is the floating-point work Russ Cox contributed to strconv.
Cox published Floating-Point Printing and Parsing Can Be Simple And Fast in January, describing a new scaling algorithm he calls uscale. It simplifies the ugly problem of converting between binary floating-point values and their decimal text representations while also being extremely fast.
According to Cox's benchmarks, his printing implementation beats algorithms including Ryū, Schubfach and Dragonbox, while the parsing implementation beats Eisel-Lemire. The implementation subsequently landed in Go and is used for Go 1.27's floating-point parsing and formatting.
This is exactly the sort of Go improvement I love. There is no new syntax to advertise and most developers will never know it happened. Existing programs simply get a better implementation underneath them.
Russ Cox is also worth knowing if you use Go.
Robert Griesemer, Rob Pike and Ken Thompson began designing Go in 2007. Cox and Ian Lance Taylor joined the effort in 2008 and helped build the compilers and standard library before Go was publicly released in 2009. Cox later served as Go's technical lead for more than a decade and has been responsible for an enormous amount of the engineering philosophy, tooling and infrastructure around the language.
ACM recently interviewed Cox, and his explanation of software engineering sounds a lot like why I continue to like Go: simplicity scales better than complexity, programming becomes software engineering when you add time and other people, and tests are primarily there to protect what happens tomorrow.
That philosophy shows up all over Go 1.27.
The cryptography work may be the best example.
The new crypto/mldsa package implements the NIST-standardized ML-DSA post-quantum signature scheme. Go's X.509 and TLS implementations understand ML-DSA as well, and Go 1.27 also supports ML-KEM-1024 key exchange.
I love how proactive the Go cryptography team has been about post-quantum cryptography.
Filippo Valsorda, one of Go's primary cryptography maintainers, wrote in April that his own assessment of the timeline had changed significantly. In A Cryptography Engineer's Perspective on Quantum Computing Timelines, he argues that waiting for perfect post-quantum protocols has become the riskier option and that the industry needs to start deploying what is good enough now.
His concern is not that a cryptographically relevant quantum computer definitely arrives on a particular date. It is that credible estimates have moved close enough that systems being designed today can no longer safely assume classical public-key cryptography will remain secure throughout their useful lives.
Putting ML-DSA directly into Go's standard library makes doing the responsible thing considerably easier.
Then there is uuid.
Go finally has a standard uuid package supporting parsing, UUIDv4 and UUIDv7. That means a lot of Go projects no longer need an external dependency just to create an identifier.
I expect a wave of drive-by pull requests replacing github.com/google/uuid with the standard library package as projects move to Go 1.27. The Google UUID project is already discussing how to help users transition.
Kubernetes still carries github.com/google/uuid, so I give it about five minutes before somebody sends that pull request.
One thing that has not changed is the Go website's refusal to syntax-highlight its code.
Every time I land on a Go blog post containing a substantial example I am a little surprised by how much harder the code is to visually parse than it needs to be.
There is some history behind that.
In a 2012 golang-nuts discussion about adding syntax highlighting to the Go Playground, Rob Pike argued that syntax highlighting was juvenile and compared it with the colored rods used to teach children arithmetic. He preferred monochrome code.
That certainly explains the aesthetic.
I still disagree with it.
Syntax highlighting is not decoration. Used well, it is another layer of information that makes structure easier to recognize. There is no reason a programming-language website should intentionally make code slower to scan because one of its creators prefers monochrome text.
That complaint aside, Go 1.27 is an unusually good release.
The things I was excited about in the draft survived intact, and some of the most interesting work is almost invisible: faster number conversion, better allocation paths, better leak detection, less dependency weight and cryptography being prepared for threats that have not arrived yet.
I really love Go.
I have not been writing as many tools in it lately, and going through this release makes me miss it.