Go 1.26: What's New and Why It Matters

Go 1.26 landed on February 10, 2026, and this one has some genuinely exciting stuff in it. Not the usual “minor standard library tweaks” release. There are real language changes, a new garbage collector enabled by default, and a goroutine leak detector that could save you hours of debugging.

I’ve gone through the full release notes so you don’t have to.

Here’s what actually matters.

The Big Stuff

1. new() Now Accepts Expressions

This is one of those changes that seems small until you realize how annoying the old way was.

Previously, new could only take a type:

p := new(int) // creates a *int pointing to zero value

If you wanted a pointer to a specific value, you had to do this:

age := 30
p := &age

Or write a helper function:

func ptr[T any](v T) *T {
    return &v
}

Every Go codebase has some version of that ptr helper. It’s one of those micro-annoyances that you stop noticing after a while.

In Go 1.26, new accepts an expression:

p := new(30) // creates a *int pointing to 30

Where this really shines is struct initialization with optional pointer fields. If you’ve ever worked with JSON or protobuf in Go, you know the pain:

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

// Before: awkward
age := yearsSince(born)
p := Person{Name: name, Age: &age}

// After: clean
p := Person{
    Name: name,
    Age:  new(yearsSince(born)),
}

No temporary variable. No helper function. Just new(expr) and move on.

2. Self-Referential Generic Constraints

Go’s generics just got more powerful. Previously, a generic type couldn’t reference itself in its own type parameter list. That restriction is now lifted.

type Adder[A Adder[A]] interface {
    Add(A) A
}

func algo[A Adder[A]](x, y A) A {
    return x.Add(y)
}

If you’ve worked with generics in Rust or Java, this pattern (sometimes called F-bounded polymorphism) will be familiar. It lets you write interfaces that say “I work with things that are like me” — useful for math types, builder patterns, and anything where a method needs to return the same concrete type.

This was previously impossible in Go without workarounds. Now it just works.

3. The Green Tea Garbage Collector (Enabled by Default)

This is the headline performance improvement. The Green Tea GC was experimental in Go 1.25 and is now the default.

What it does:

• 10–40% reduction in GC overhead for programs that allocate heavily
• Better locality and CPU scalability when marking and scanning small objects
• Additional ~10% improvement on newer AMD and Intel CPUs (Zen 4+, Ice Lake+) thanks to vector instructions for object scanning

For most Go developers, this is free performance. You don’t need to change any code. Your programs just get faster.

If something breaks (unlikely, but it’s a new GC), you can disable it:

GOEXPERIMENT=nogreenteagc go build

This opt-out will be removed in Go 1.27, so if you hit issues, file a bug.

4. Goroutine Leak Detection (Experimental)

This might be my favorite feature in the release, even though it’s still experimental.

Go makes it incredibly easy to spawn goroutines and incredibly easy to leak them. A leaked goroutine is one that’s blocked forever, waiting on a channel no one will ever send to, or a mutex no one will ever unlock.

Go 1.26 introduces a new goroutineleak profile that detects these leaks using the garbage collector. The logic: if a goroutine is blocked on a concurrency primitive, and that primitive is unreachable from any runnable goroutine, then it’s leaked.

Here’s a classic example:

func processWorkItems(ws []workItem) ([]workResult, error) {
    ch := make(chan result)
    for _, w := range ws {
        go func() {
            res, err := processWorkItem(w)
            ch <- result{res, err}
        }()
    }

    var results []workResult
    for range len(ws) {
        r := <-ch
        if r.err != nil {
            return nil, r.err // early return = goroutine leak
        }
        results = append(results, r.res)
    }
    return results, nil
}

That early return on error means the remaining goroutines will block on ch <- result{...} forever. The channel becomes unreachable, and Go 1.26 can now detect and report it.

To enable it:

GOEXPERIMENT=goroutineleakprofile go build

It also exposes an HTTP endpoint at /debug/pprof/goroutineleak if you’re using net/http/pprof. The team plans to enable this by default in Go 1.27.

I’d recommend turning this on in your test suite now. Goroutine leaks are the kind of bug that silently eats memory in production until someone notices the OOM kills at 3 AM.

go fix Got a Complete Rewrite

The go fix command has been rebuilt from scratch. It’s no longer the dusty tool that applied Go 1.0-era fixes nobody needed anymore.

The new go fix is a modernizer. It automatically updates your codebase to use current Go idioms and APIs. The initial suite includes dozens of fixers, plus a source-level inliner that lets you automate your own API migrations with //go:fix inline directives.

It’s built on the same analysis framework as go vet, which means the same analyzers that find problems can now fix them too.

If you haven’t run go fix in years (who has?), it’s worth running against your codebase now. It won’t change behavior — just modernize syntax.

Other Notable Changes

A quick rundown of the rest:

• ~30% faster cgo calls. If your Go code calls C code, the overhead just dropped significantly.
• Heap base address randomization on 64-bit platforms. Security hardening that makes memory address prediction harder for attackers using cgo.
• Stack allocation for slices in more situations. The compiler is smarter about keeping slice backing stores on the stack instead of the heap. Free performance.
• New crypto/hpke package. Hybrid Public Key Encryption (RFC 9180) with post-quantum hybrid KEM support. If you do crypto work, this is significant.
• Experimental SIMD package (simd/archsimd). Access to 128/256/512-bit vector operations on amd64. Enabled with GOEXPERIMENT=simd. The API isn’t stable yet, but it’s a signal of where Go is heading for performance-critical code.
• New runtime/secret package (experimental). Securely erases sensitive data like cryptographic keys from memory. Important for forward secrecy.
• bytes.Buffer.Peek — finally, you can peek at buffer contents without advancing. Small but useful.
• Pprof defaults to flame graph view. The old graph view is still available, but flame graphs are the default now. Good call.
• go mod init defaults to a lower Go version. New modules created with Go 1.26 will have go 1.25.0 in their go.mod, encouraging backward compatibility.

How to Upgrade

go install golang.org/dl/go1.26.0@latest
go1.26.0 download

Or if you manage Go through your package manager, update as usual. The official download page has binaries for all platforms.

Should You Upgrade?

Yes. This is a strong release.

The Green Tea GC alone makes it worth it — free performance with zero code changes. The new(expr) syntax eliminates one of Go’s most common minor annoyances. The goroutine leak profiler (even as an experiment) is a tool every Go developer should have in their toolbox.

The self-referential generics lift is less immediately practical for most codebases, but it’s a sign that Go’s type system is maturing in the right direction.

Go 1.26 is the kind of release that doesn’t break anything but makes everything a little better. That’s what a good Go release looks like.

For the full release notes, see go.dev/doc/go1.26.