Go 1.26 Quietly Fixed the Things That Were Actually Annoying | by Cheikh seck | Jun, 2026 | Towards DevSitemapOpen in appSign up<br>Sign in
Medium Logo
Get app<br>Write
Search
Sign up<br>Sign in
Towards Dev
A publication for sharing projects, ideas, codes, and new theories.
Go 1.26 Quietly Fixed the Things That Were Actually Annoying
Most release notes read like change logs. This one reads like a list of apologies. Here’s what changed, why it matters, and what you can ignore.
Cheikh seck
6 min read·<br>Just now
Listen
Share
I read the Go 1.26 release notes the way I read most release notes: skimming for the headline feature, ignoring the rest, and going back to my code.<br>Then I read them again.<br>What I noticed the second time is that almost nothing in 1.26 is flashy. There’s no new language feature that will trend on Hacker News. There’s no “Go gets async” moment. What there is, instead, is a release that quietly fixes the things that have been annoying Go developers for years — and ships one genuinely important runtime change that almost every production service will benefit from.<br>Let me walk you through what actually changed, what you should care about, and what you can safely ignore.<br>Press enter or click to view image in full size
The headline: Green Tea is now the default garbage collector<br>If you only read one section of this article, read this one.<br>Go 1.25 shipped the Green Tea garbage collector as an opt-in experiment. Go 1.26 makes it the default. The Go team is reporting 10–40% reduction in GC overhead in real-world programs, with another ~10% on top of that if you’re running on Intel Ice Lake or AMD Zen 4 or newer (because the new collector uses vector instructions for scanning small objects).<br>I want to be careful with that number because “10–40%” is the kind of range that means nothing without context. Here’s the context: this is the reduction in time spent in GC, not the reduction in total runtime. If your service spends 20% of its CPU in GC, you’re looking at dropping to somewhere between 12% and 18%. That’s not a rewrite. That’s a free lunch.<br>You don’t need to do anything to get this. If you upgrade to 1.26, your service gets it. If you were already running with GOEXPERIMENT=greenteagc in 1.25, you can remove that flag.
The language change you’ll actually use: new() with an expression<br>This is small. It’s also the change I’ve been wanting for years.<br>In Go 1.26, the built-in new function accepts an expression as its operand:<br>func personJSON(name string, born time.Time) ([]byte, error) {<br>return json.Marshal(Person{<br>Name: name,<br>Age: new(yearsSince(born)), // ← this is new<br>})<br>}Before 1.26, you had to write this as a two-step:<br>age := yearsSince(born)<br>return json.Marshal(Person{<br>Name: name,<br>Age: &age,<br>})The use case is narrow but real: any time you have a pointer-to-optional-value field (JSON, protobuf, gRPC), you can now populate it inline. It’s the kind of change that doesn’t show up in benchmarks but shows up in every code review you’ve ever done.
The generics change you’ll probably never use directly<br>The restriction that a generic type can’t refer to itself in its own type parameter list has been lifted:<br>type Adder[A Adder[A]] interface {<br>Add(A) A<br>}This is the kind of feature that library authors will love and application developers will never type. If you’re building a math library or a collection framework, this unlocks cleaner abstractions. If you’re building web services, you can skip this section.<br>The tool change that will save you hours: go fix is reborn<br>This is the change I’m most excited about, and it’s the one nobody is talking about.<br>go fix has been rewritten from scratch. It's now the home of Go's modernizers — dozens of automated fixers that update your code to use modern idioms and APIs. It uses the same analysis framework as go vet, which means the diagnostics you already trust can now suggest and apply fixes.<br>The killer feature is the source-level inliner. If you maintain a library and want your users to migrate to a new API, you can write a //go:fix inline directive and go fix will rewrite their code automatically.<br>In practice, this means:<br>Upgrading a Go project to 1.26 is now go fix ./... away from using the new idioms.<br>Migrating off deprecated APIs is no longer a manual grep-and-replace.<br>Library authors can ship breaking changes with an automated migration path.<br>If you’ve ever maintained a large Go codebase and dreaded the “upgrade Go version” PR, this is for you.<br>The smaller runtime changes worth knowing<br>Three other runtime changes shipped in 1.26:<br>Get Cheikh seck’s stories in your inbox
Join Medium for free to get updates from this writer.
Subscribe
Subscribe
Remember me for faster sign in
Faster cgo calls. If you have a Go service that calls into C libraries (database drivers, image processing, anything that wraps a C API), cgo overhead just got cheaper. The Go team hasn’t published exact numbers, but the change targets the per-call overhead that adds up in hot...