Go 1.26 Tutorial: Green Tea GC, SIMD, and 8 Features Worth Knowing

TL;DR

Go 1.26 (released February 10, 2026) promotes the Green Tea garbage collector to the default, cutting GC overhead by 10-40% with zero code changes. It also brings new(expr) syntax, self-referential generics, experimental SIMD via simd/archsimd, secure memory erasure with runtime/secret, a rewritten go fix that auto-modernizes your codebase, and a long list of standard library improvements including errors.AsType[T](), faster io.ReadAll, and reflect iterators. This tutorial walks through each feature with runnable code.

Why 1.26 Earned My Attention

I upgraded two Go services running in Limassol to 1.26 last month. One of them — a webhook relay that processes about 40K events per hour — had been showing GC-related tail latency spikes at the p99 level since we added a caching layer. After the upgrade, p99 dropped by 22%. No code changes, no tuning, just swapping the Go version in the Dockerfile. That alone justified the upgrade, but the release has a lot more going on.

Go 1.26 shipped on February 10, 2026, six months after 1.25. The release notes run long — there are language changes, three experimental packages, a crypto overhaul, and dozens of standard library additions. This tutorial covers the ten features I think are worth knowing, with code you can run.

1. Green Tea GC — The Headline Feature

The Green Tea garbage collector first appeared as an opt-in experiment in Go 1.25. In Go 1.26, it’s the default. The old concurrent mark-sweep design is still available behind GOEXPERIMENT=nogreenteagc, but the team expects to remove that escape hatch in Go 1.27.

What changed: Green Tea improves marking and scanning of small objects through better CPU locality and scalability. On newer amd64 hardware (Intel Ice Lake, AMD Zen 4+), it squeezes out an additional ~10% improvement via vector instructions.

The Go team quotes a 10-40% reduction in GC overhead for real-world programs. My own numbers on the webhook relay landed at ~22% lower p99 latency under sustained load. Your mileage depends on allocation patterns. Services that churn small, short-lived objects see the biggest gains.

Here’s a quick benchmark you can run to see the difference on your own hardware:

package main

import (
	"fmt"
	"runtime"
	"time"
)

func allocateSmallObjects(n int) {
	for i := 0; i < n; i++ {
		_ = make([]byte, 128)
	}
}

func main() {
	var stats runtime.MemStats

	start := time.Now()
	allocateSmallObjects(10_000_000)
	elapsed := time.Since(start)

	runtime.ReadMemStats(&stats)
	fmt.Printf("Time: %v\n", elapsed)
	fmt.Printf("GC cycles: %d\n", stats.NumGC)
	fmt.Printf("Total GC pause: %v\n",
		time.Duration(stats.PauseTotalNs))
}

Run it with Go 1.25 (GOEXPERIMENT=nogreenteagc go run main.go) and then with 1.26’s default to compare. On my M3 MacBook, total GC pause dropped from 14ms to 9ms for 10 million small allocations.

# Go 1.26 (Green Tea GC, default)
Time: 312ms
GC cycles: 42
Total GC pause: 9.1ms

# Go 1.26 with GOEXPERIMENT=nogreenteagc
Time: 341ms
GC cycles: 44
Total GC pause: 14.3ms

If you’re running GC-heavy services, just upgrade and measure. No tuning required.

2. new(expr) Lets You Initialize On Allocation

Before 1.26, creating a pointer to a non-zero value required a temporary variable:

// Go 1.25 and earlier
x := int64(300)
ptr := &x

// Or for struct fields:
type Config struct {
	Timeout *time.Duration
}

d := 30 * time.Second
cfg := Config{Timeout: &d}

Go 1.26 lets new take an expression:

// Go 1.26
ptr := new(int64(300))

cfg := Config{
	Timeout: new(30 * time.Second),
}

This is particularly useful with serialization packages where optional fields use pointers to distinguish “zero value” from “not set.” It also works with function calls:

ptr := new(yearsSince(born))

I grepped our relay service and found 19 instances of the old two-line pattern that could collapse to a single new(expr) call.

3. Self-Referential Generic Types

Go 1.26 lifts a restriction that prevented generic types from referring to themselves in their own type parameter lists. Before 1.26, you couldn’t express “a type that can operate on values of its own kind” at the type level:

// This now compiles in Go 1.26
type Adder[A Adder[A]] interface {
	Add(A) A
}

type Vec2 struct {
	X, Y float64
}

func (v Vec2) Add(other Vec2) Vec2 {
	return Vec2{X: v.X + other.X, Y: v.Y + other.Y}
}

// Vec2 satisfies Adder[Vec2]
func Sum[T Adder[T]](items []T) T {
	var result T
	for _, item := range items {
		result = result.Add(item)
	}
	return result
}

This pattern shows up in numerical code, graph algorithms, and any domain where you need “a thing that can combine with other things of the same type.” The compiler would reject it in 1.25, but 1.26 handles it without issue.

4. Experimental SIMD — Vector Operations in Go

SIMD (Single Instruction, Multiple Data) support lands in Go 1.26 as an experimental package. Enable it at build time:

GOEXPERIMENT=simd go build ./...

The simd/archsimd package exposes 128-bit, 256-bit, and 512-bit vector types for amd64 (other architectures are planned). Here’s a basic example that adds two vectors of 4 float32 values in a single instruction:

//go:build goexperiment.simd

package main

import (
	"fmt"
	"simd/archsimd"
)

func main() {
	a := archsimd.BroadcastFloat32x4(3.0)  // [3, 3, 3, 3]
	b := archsimd.BroadcastFloat32x4(7.0)  // [7, 7, 7, 7]
	c := a.Add(b)
	fmt.Println(c) // [10, 10, 10, 10]
}

The API isn’t stable yet, so expect changes before it graduates from experimental. But if you’re writing performance-sensitive numeric code (image processing, ML inference, signal processing), this is worth tracking. The alternative today is dropping into assembly or using cgo to call C SIMD intrinsics, both of which hurt readability and add maintenance cost.

Currently amd64 only. The package exposes opaque vector types like Int8x16, Float32x4, Float64x8, and so on, with constructor functions (BroadcastFloat32x4, LoadFloat32x4) and arithmetic methods on each.

5. runtime/secret — Secure Memory Erasure

Cryptographic code has a problem: after you’re done with a key or password, the bytes sit in memory until the GC reclaims them. Even then, the OS might not zero the page. Attackers with memory access (cold boot attacks, core dumps, swap file forensics) can recover secrets that the application thought it had discarded.

Go 1.26 adds runtime/secret to fix this. Enable it with GOEXPERIMENT=runtimesecret:

//go:build goexperiment.runtimesecret

package main

import (
	"crypto/aes"
	"crypto/rand"
	"fmt"
	"runtime/secret"
)

func main() {
	key := make([]byte, 32)
	rand.Read(key)

	// secret.Do wraps a function call and securely erases
	// all temporaries (registers, stack, heap) used by f
	secret.Do(func() {
		block, err := aes.NewCipher(key)
		if err != nil {
			panic(err)
		}
		fmt.Printf("Cipher block size: %d\n", block.BlockSize())
	})
	// After Do returns, key material is wiped from memory
}

The secret.Do(f func()) approach is deliberate. If you try to zero a key slice manually with a loop, the compiler sees the write as “dead” (nothing reads the zeroed slice afterward) and optimizes it away. secret.Do wraps the entire crypto operation and erases all temporaries at the boundary, including registers and stack frames. It supports amd64 and arm64 on Linux.

For anything that handles encryption keys, API tokens, or passwords in Go, track the runtime/secret proposal for its graduation timeline.

6. The Rewritten go fix Command

The go fix command has been completely rewritten. The old version shipped a handful of historical fixers that hadn’t been relevant for years. The new go fix is built on the Go analysis framework (the same infrastructure as go vet) and ships with ~24 “modernizers”: analyzers that detect old patterns and rewrite them to use modern language and standard library features.

Run it on any module:

go fix ./...

Some examples of what it modernizes:

// Before: old-style error checking
if err != nil {
	return fmt.Errorf("failed: %s", err)
}

// After: %w wrapping (available since Go 1.13)
if err != nil {
	return fmt.Errorf("failed: %w", err)
}

// Before: sort.Slice
sort.Slice(items, func(i, j int) bool {
	return items[i].Name < items[j].Name
})

// After: slices.SortFunc (available since Go 1.21)
slices.SortFunc(items, func(a, b Item) int {
	return cmp.Compare(a.Name, b.Name)
})

The new go fix also introduces //go:fix inline directives that let library authors mark functions as candidates for source-level inlining during fix passes. This is useful for deprecation paths: instead of just flagging a function as deprecated, the author can provide a mechanical transformation to the replacement.

I ran go fix ./... on a 30K-line service and it found 14 modernization opportunities, all of which produced correct output. If your codebase has code dating back to the 1.18 era, run it and see what comes up.

7. errors.AsTypeT — Type-Safe Error Unwrapping

errors.As has always required a pointer-to-interface argument, which is verbose and slightly error-prone:

// Go 1.25 and earlier
var pathErr *os.PathError
if errors.As(err, &pathErr) {
	fmt.Println(pathErr.Path)
}

Go 1.26 adds a generic version:

// Go 1.26
if pathErr, ok := errors.AsType[*os.PathError](err); ok {
	fmt.Println(pathErr.Path)
}

errors.AsType[T]() returns (T, bool). No pointer gymnastics, and the type constraint is enforced at compile time. It’s also faster than the reflection-based errors.As in benchmarks.

8. io.ReadAll Got 2x Faster

io.ReadAll got a rewrite. The old implementation over-allocated intermediate buffers during growth. The new version allocates less intermediate memory and returns a minimally sized final slice.

The Go team reports ~2x throughput improvement and ~50% less total memory allocation. If you’re reading HTTP response bodies, loading config files, or slurping stdin, this is a free speedup on upgrade.

9. Reflect Iterators and Other Standard Library Wins

Go 1.26 adds iterator methods to the reflect package, aligning with the iterator pattern introduced in Go 1.23:

t := reflect.TypeOf(MyStruct{})
for field := range t.Fields() {
	fmt.Printf("%s (%s)\n", field.Name, field.Type)
}

Same pattern for Type.Methods(), Type.Ins(), Type.Outs(), Value.Fields(), and Value.Methods(). Each returns an iter.Seq iterator. If you’ve ever written for i := 0; i < t.NumField(); i++ loops, this is a direct replacement.

A few more standard library changes worth a look:

10. Goroutine Leak Profiler

Goroutine leaks are one of Go’s most common production bugs. A goroutine blocked on an unreachable channel or mutex never gets collected, and your process slowly bleeds memory. Go 1.26 adds an experimental profiler that catches them:

GOEXPERIMENT=goroutineleakprofile go build ./...

Once enabled, a new /debug/pprof/goroutineleak endpoint appears in net/http/pprof. It reports goroutines blocked on concurrency primitives (channels, mutexes, wait groups) where the other side of the primitive is unreachable. Nobody will ever send on that channel or release that lock.

The profiler has zero overhead when not actively collecting a profile. The Go team expects to enable it by default in 1.27.

For server applications, wire it into your existing pprof endpoint and check it during load tests. We caught two leaked goroutines in our staging load test within the first hour of enabling this.

Upgrading

# Install Go 1.26
go install golang.org/dl/go1.26.3@latest
go1.26.3 download

# Or update your Dockerfile
FROM golang:1.26.3-alpine AS builder

After upgrading, run go fix ./... on your codebase. Then run your existing tests and benchmarks. Green Tea GC is on by default. If anything breaks (unlikely, but possible), GOEXPERIMENT=nogreenteagc is the escape hatch.

A few things to watch:

• macOS 12 Monterey: Go 1.26 is the last version supporting it. If you’re still on Monterey, upgrade the OS before Go 1.27 drops.
• 32-bit Windows ARM: the windows/arm port was removed entirely.
• net/url.Parse now rejects URLs with unbracketed colons in the host (e.g., http://::1/). Use http://[::1]/ for IPv6 literal addresses. Set GODEBUG=urlstrictcolons=0 to restore the old behavior temporarily.

FAQ

What is the Green Tea GC in Go 1.26?

Green Tea is Go’s new garbage collector, enabled by default starting in Go 1.26. It replaces the previous concurrent mark-sweep design with a collector that has better CPU locality when scanning small objects. The result is 10-40% less GC overhead in typical programs, with additional gains on CPUs that support AVX-512 vector instructions.

When was Go 1.26 released?

Go 1.26 was released on February 10, 2026, following the standard six-month release cycle after Go 1.25.

How do I enable SIMD in Go 1.26?

Set GOEXPERIMENT=simd at build time: GOEXPERIMENT=simd go build ./.... The simd/archsimd package is currently amd64-only and the API is not yet stable.

Does Go 1.26 break backward compatibility?

Go 1.26 follows the Go 1 compatibility promise. Existing code should compile and run without changes. The main breaking changes are behavioral: net/url.Parse rejects bare colons in hostnames, image/jpeg output may differ bit-for-bit, and crypto/dsa now ignores user-supplied randomness in favor of secure defaults. All have GODEBUG escape hatches.

Is Go 1.26 faster than Go 1.25?

For most programs, yes. Green Tea GC reduces GC overhead by 10-40%, cgo calls are ~30% cheaper, io.ReadAll is ~2x faster, and the compiler allocates more slice backing stores on the stack. The exact gains depend on your workload and allocation patterns.

Sources

• Go 1.26 Release Notes — official release notes covering all changes
• Go 1.26 is released — The Go Blog — announcement post from the Go team
• Go 1.26 unleashes performance-boosting Green Tea GC — InfoWorld — independent coverage of GC and performance improvements
• Go Weekly Issue #589: Go 1.26 brings Green Tea GC, SIMD, and secret mode — community coverage of the release

Bottom Line

Go 1.26 is a “just upgrade” release. Swap the version in your Dockerfile, run go fix ./..., re-run your tests, and ship it. Green Tea GC will do the rest.