Go 1.26: What's New, Release History & Support Lifecycle

What Is New in Go 1.26

What does the Green Tea garbage collector change in Go 1.26?

The Green Tea garbage collector, previously an opt-in experiment in Go 1.25, is now the default GC in Go 1.26 and represents the most impactful runtime change in this release. It improves marking and scanning of small objects through better CPU locality and scalability, targeting the workloads where Go programs spend the most GC time.

Benchmark results vary by workload, but teams running GC-heavy services should expect somewhere between a 10--40% reduction in garbage collection overhead. On newer amd64 platforms (Intel Ice Lake, AMD Zen 4 and later), the GC also leverages vector instructions for scanning small objects, delivering an additional ~10% improvement on top of that baseline.

In practice, the transition should be transparent. If you hit regressions -- particularly around memory layout assumptions or tight latency budgets -- you can disable the new GC at build time:

GOEXPERIMENT=nogreenteagc go build ./...

Watch out for this opt-out being removed in Go 1.27. If you need to disable it, file a bug with the Go team now so it can be addressed before the window closes.

How does Go 1.26 improve security for programs using cgo?

Go 1.26 introduces heap base address randomization on 64-bit platforms, making it significantly harder for attackers to predict memory layouts and exploit memory safety issues in cgo-enabled code. This runs automatically at startup with no code changes required.

On top of that, cgo call overhead itself has been cut by approximately 30% at the baseline. For services with tight hot paths that must cross the Go/C boundary -- think embedded databases, GPU bindings, or OS-level integrations -- this is a meaningful free win.

Additionally, the crypto/subtle.WithDataIndependentTiming function now propagates timing isolation to spawned goroutines and their descendants, and correctly carries that state across cgo call boundaries in both directions. Most teams doing side-channel-sensitive crypto work will want to verify their isolation boundaries cover the full goroutine tree.

What cryptography changes landed in Go 1.26 and do they require migration?

Go 1.26 ships a significant batch of crypto improvements, most of which are backward-compatible but a few of which carry migration implications. The biggest headline is the new crypto/hpke package, a production-ready implementation of Hybrid Public Key Encryption (RFC 9180) including post-quantum hybrid KEMs -- useful for any teams building forward-secret key exchange into their protocols.

Post-quantum key exchange is also now on by default in crypto/tls: SecP256r1MLKEM768 and SecP384r1MLKEM1024 are enabled automatically. Most TLS stacks will just pick this up. You can disable it with Config.CurvePreferences or the tlssecpmlkem=0 GODEBUG if you need to target clients that choke on larger key exchange payloads.

The deeper migration concern is the crypto random parameter changes. Across crypto/rsa, crypto/ecdsa, crypto/ecdh, crypto/dsa, and crypto/rand, the rand io.Reader parameter passed to key generation and signing functions is now silently ignored -- the runtime always uses its own secure random source. If your test suite injects a deterministic rand for reproducibility, that approach no longer works. Migrate to testing/cryptotest.SetGlobalRandom instead.

import "testing/cryptotest"

func TestKeyGeneration(t *testing.T) {
    cryptotest.SetGlobalRandom(t, deterministicReader)
    key, err := rsa.GenerateKey(nil, 2048) // rand param ignored; SetGlobalRandom takes effect
    // ...
}

How does the revamped go fix command work in Go 1.26?

The go fix command has been completely rewritten in Go 1.26 and is now a fully automated code modernization framework -- not just a handful of one-off migration scripts. It is built on the same analysis framework as go vet, which means its fixers are reliable, composable, and auditable in the same way diagnostics are.

The initial release ships dozens of fixers that update code to use modern language and standard library features. You can also write your own automated API migrations using //go:fix inline directives on functions you want inlined away, enabling a clean deprecation-and-migration workflow for library authors.

# Apply all available modernizers to your module
go fix ./...

# Preview what would change without applying
go fix -list ./...

This matters especially if you maintain a large codebase that has accumulated pre-generics patterns, old io/ioutil calls, or other idioms that newer Go versions supersede. The old historical fixers (which were already obsolete) have been removed.

What new language features does Go 1.26 introduce?

Go 1.26 adds two notable language changes. First, the built-in new function now accepts an initializer expression, not just a type. This removes an awkward pattern that anyone working with pointer-optional fields in JSON or protobuf structs will recognize immediately.

Before Go 1.26, initializing a pointer field inline required a helper function or a separate variable. Now you can write this directly:

type Person struct {
    Name string  `json:"name"`
    Age  *int    `json:"age"` // optional
}

// Old approach: required a helper or temp variable
age := yearsSince(born)
p := Person{Name: name, Age: &age}

// Go 1.26: initialize inline
p := Person{
    Name: name,
    Age:  new(yearsSince(born)),
}

Second, generic types can now reference themselves in their own type parameter constraints. This was previously rejected by the compiler and limited the expressiveness of recursive type hierarchies. A type like Adder[A Adder[A]] -- where an interface requires that implementors be combinable with themselves -- is now valid. In practice, this unlocks cleaner algebra-style interfaces and simplifies some functional programming patterns in Go.