Go 1.26 trims GC overhead with stack slices

Go 1.25 and 1.26 are doing something very practical: they are reducing garbage collector work by stack-allocating slices in more cases than before. In one notable case, Go 1.26 even stack-allocates slices that later escape to the heap, which is the kind of compiler behavior change that can quietly improve real-world latency without any code changes.

This week’s Golang Weekly issue also packed in a few other signals worth watching: a deeper look at naming in Go, a compiler fix for cycle detection, a new release of GoLand, and a fresh pgx release with protocol and auth updates. If you build production Go systems, this was a useful week.

Go 1.26 keeps more slices off the heap

The biggest technical detail in the issue is the compiler work around stack allocation. The short version: Go 1.25 and 1.26 can keep more slices on the stack, which means less pressure on the garbage collector. For high-throughput services, that matters because heap allocations are one of the easiest ways to add background work your app did not need.

The interesting part is the 1.26 improvement. The compiler can now stack-allocate some slices even when they eventually escape. That sounds odd until you remember how compilers reason about lifetimes. If the compiler can prove the temporary work happens safely before escape, it can do the cheaper thing first and still preserve behavior later.

That kind of optimization matters most in code that creates lots of short-lived slices, especially request handlers, parsers, and data transformation pipelines. It is the sort of change that rarely gets a flashy demo, but it can shave allocation counts in places that show up immediately in pprof.

• Go 1.25 and 1.26 both improve stack allocation for slices.
• Go 1.26 extends the optimization to some slices that later escape.
• Less heap allocation usually means less GC pressure.
• Lower GC pressure often helps tail latency more than average latency.

Naming, type checking, and the boring stuff that saves time

Alex Edwards’ Go naming conventions guide is the kind of article people bookmark and then quietly send to teammates six months later. It covers identifiers, filenames, packages, and a useful idea he calls avoiding chatter. That is the habit of stripping names down so the important part is easy to read.

There is a reason naming articles keep getting attention: bad names create friction everywhere. They slow code review, make package APIs harder to scan, and turn otherwise simple refactors into archaeology. Good names do the opposite. They reduce the amount of thinking required to understand a file before you even run tests.

“There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton

That quote is older than Go itself, but it still lands because it is true in a very unglamorous way. Naming is one of the few engineering tasks where the cost compounds every time someone reads the code. You pay for a bad name in review, in debugging, in documentation, and again when the next person copies the pattern.

The other compiler-related story in the issue is a type-system fix from the Go team. In Go 1.26, the type checker now detects when an incomplete type is used in a way that requires it to be fully defined, and it turns a confusing failure into a cycle error. That is the sort of diagnostics work that saves hours because it moves the failure closer to the real problem.

• Alex Edwards’ guide covers identifiers, filenames, packages, and “avoiding chatter.”
• Go 1.26 improves error reporting for incomplete types used too early.
• Cleaner compiler errors reduce debugging time when generics or recursive types get tricky.
• Better names and better errors both cut mental overhead in large codebases.

Tools and libraries: Go keeps expanding sideways

This issue also showed how broad the Go ecosystem has become. JetBrains shipped GoLand 2026.1 with guided syntax updates for Go 1.26 and support for git worktrees. That matters if you live in large repos, where worktrees are often a cleaner way to juggle branches than constantly stashing changes.

On the library side, pgx 5.9 added SCRAM-SHA-256-PLUS, OAuth authentication, Postgres protocol 3.2, and tsvector support. It also requires Go 1.25+, which is a reminder that the ecosystem is moving in lockstep with the language release train.

And then there is ncruces/go-sqlite3 v0.33.0, which has moved away from its earlier WebAssembly setup and now uses wasm2go to translate SQLite into Go. That is a fascinating engineering tradeoff: fewer foreign-language runtime pieces, but a very different implementation path under the hood.

• GoLand 2026.1 adds Go 1.26 syntax guidance and git worktree support.
• pgx 5.9 adds SCRAM-SHA-256-PLUS, OAuth, protocol 3.2, and tsvector support.
• go-sqlite3 v0.33.0 now uses wasm2go behind the scenes.
• Bubbles 2.1 adds auto-resizing textareas for TUIs.
• Fantasy v0.17.0 adds Anthropic Computer Use support.

What this issue says about Go right now

The strongest theme in this issue is that Go keeps getting more capable without losing its bias toward practical engineering. The compiler is getting smarter about allocations and type errors. The ecosystem is shipping better database, CLI, desktop, and agent tooling. And the editor community is still publishing the kind of advice that helps teams write code other people can maintain.

There is also a more subtle signal here: the language is maturing in ways that matter to people running production systems, not just people reading release notes. Stack allocation improvements, better diagnostics, and protocol support in core libraries all point in the same direction. Go is spending less of your CPU budget on avoidable overhead and more of it on the work you actually asked it to do.

If you are maintaining a Go service today, the most actionable takeaway is simple: test your code on Go 1.26 early and re-run your allocation benchmarks. If the compiler can keep more slices on the stack, you may see a free win. If your code depends on older assumptions about type errors or database behavior, this is also the right moment to clean those up before the next release cycle lands.

My bet is that the next few Go releases will keep squeezing out these small but measurable wins in allocation behavior, diagnostics, and tooling. The question for teams is whether they will benchmark and upgrade quickly enough to notice them.