Go Turns 17

Austin Clements, for the Go team

10 November 2026

Today, November 10th, we celebrate the 17th anniversary of Go’s open source release!

Over the past year, we released Go 1.26 in February and Go 1.27 in August, alongside a steady stream of releases across our golang.org/x libraries and developer tools. Meanwhile, the pace of change across the software industry continues to accelerate, driven by shifting hardware, evolving security threats, and the rapid rise of AI-assisted development and agentic systems.

In a tumultuous time for the industry, Go aims to be a steady hand on the tiller. Our goal is to keep Go grounded in its foundational principles of simplicity, reliability, efficiency, and an unwavering commitment to compatibility, while adapting to modern hardware, production workloads, and developer workflows. Increasingly, our investments serve a dual purpose: what helps human engineers write, understand, and maintain reliable Go code at scale also provides the guardrails and authoritative context that AI coding assistants and agents need to be effective.

In the language itself, Go 1.26 and 1.27 addressed several long-standing restrictions in generics and everyday Go syntax, guided by years of real-world experience. When generics first landed in Go 1.18, methods could not declare their own type parameters, which sometimes forced awkward package-level functions and “inside-out” nested calls. Go 1.27 introduced generic methods on non-interface types (such as the new Rand.N method in math/rand/v2), allowing APIs to stay naturally organized on types and enabling readable method chaining. Together with support for self-referential type constraints in Go 1.26 and broader type inference for generic function values in Go 1.27, generics in Go feel more complete and natural than ever.

Alongside generics, two refinements to value construction make everyday Go code cleaner and more concise. Go 1.26 extended the built-in new function to accept an initial value expression, allowing new(42) or new("go1.26") without the ubiquitous newInt-style helper functions used to populate optional pointer fields in JSON and protocol buffer structs. And in Go 1.27, struct literal keys can refer directly to fields of embedded or nested structs, reducing boilerplate in composite literals.

In the standard library, our focus has been on evolving Go’s “production stack” and eliminating subtle operational traps. Few packages are as central to that as encoding/json, which has been a mainstay of Go since before Go 1.0. While its core model has held up remarkably well for over 15 years, tighter JSON standards and security expectations have turned some of its original defaults into interoperability and security hazards, such as silently accepting invalid UTF-8 or duplicate object keys and matching struct fields case-insensitively. At the same time, its buffered design prevented true streaming and limited performance. Addressing these issues while upholding Go’s compatibility promise for the millions of existing programs that depend on encoding/json meant designing a new major version of the package.

Six years in the making, the new encoding/json/v2 and encoding/json/jsontext packages reached general availability in Go 1.27. Driven by Joe Tsai, Daniel Martí, and contributors from across the Go community, this modern JSON API brings safer, stricter defaults, flexible caller- and type-specified customization, and up to 10× faster unmarshaling, while cleanly separating high-level semantic marshaling (json/v2) from low-level, reflection-free syntactic streaming (jsontext). Crucially, we didn’t leave existing code behind: the original encoding/json package is now implemented entirely in terms of v2 under the hood. Existing v1 callers get faster unmarshaling simply by upgrading, and packages using v1 and v2 interoperate seamlessly so that the ecosystem can migrate gradually without flag days.

We’ve also brought new production diagnostics to Go’s concurrency primitives. Concurrency is one of Go’s greatest strengths, but goroutines accidentally left blocked on abandoned channels or locks can silently leak memory and CPU in long-running services, and traditional goroutine profiles cannot distinguish leaked goroutines from ones legitimately waiting for work. First previewed in Go 1.26 and now generally available in Go 1.27, the new goroutine leak profiler (goroutineleak in runtime/pprof and /debug/pprof/goroutineleak in net/http/pprof) solves this for production services. Contributed by Vlad Saioc and Uber’s Programming Systems team, building on academic research with Aarhus University and Washington University in St. Louis, the profiler repurposes the garbage collector’s reachability phase to identify goroutines blocked on concurrency primitives that no runnable goroutine can ever reach. That allows it to pinpoint leaks in production with near-zero false positives and zero overhead when not in use.

In net/http, closing an HTTP/1 response body with even a single unread byte—such as a trailing newline left behind by a JSON decoder—previously forced the client to tear down the underlying TCP and TLS connection. Go 1.27’s HTTP transport now automatically drains small unread response bodies in the background on close, turning a widespread latency footgun into up to a 5× speedup for sequential HTTP/1 requests while letting application code stay clean and simple.

These releases also added several notable standard library APIs, including a native uuid package, a generic and type-safe errors.AsType, and an in-memory httptest.NewTestServer designed for virtual-time testing with testing/synctest. Existing packages saw significant speedups as well: io.ReadAll now runs twice as fast while allocating half as much memory, compress/flate compresses faster (speeding up gzip, zip, zlib, and png), and image/jpeg has a faster, more accurate encoder and decoder.

Modern CPUs look very different from the hardware Go first launched on 17 years ago, with wide vector units and deep, non-uniform memory hierarchies. A major focus of our runtime and compiler work is ensuring Go programs make full use of modern silicon, both transparently when you upgrade your toolchain and through new APIs when you need explicit control.

After debuting as an experiment in Go 1.25, the Green Tea garbage collector became the default in Go 1.26. By organizing object marking around contiguous memory spans rather than chasing pointers across the heap, Green Tea aligns with modern CPU memory architectures to reduce garbage collection overhead by 10–40% in real-world workloads—and by an additional ~10% on recent amd64 processors using AVX-512 vector instructions during scanning.

Of course, the runtime shouldn’t be the only part of a Go program that can tap into vector hardware. Without access to Single Instruction, Multiple Data (SIMD) capabilities, compute-intensive software, from cryptography and media processing to data analytics and AI, leaves a significant portion of modern silicon dark. Until recently, the only way to light up that hardware in Go was by writing and maintaining per-architecture assembly. To change that, Go 1.26 and 1.27 introduced two experimental SIMD packages: simd/archsimd, for low-level access to architecture-specific vector instructions on amd64, arm64 (NEON), and WebAssembly (wasm); and simd, a higher-level, width-agnostic API that provides portable, near-assembly performance across architectures with automatic fallback emulation.

We’ve also attacked the cost of memory allocation from multiple angles. The cheapest heap allocation is the one that never happens: in Go 1.26, the compiler began allocating initial slice backing stores on the stack at append sites—even for slices that ultimately escape to the heap—eliminating the flurry of small heap allocations that typically accompany slice growth. And for heap allocations more broadly, Go 1.27 introduced size-specialized memory allocation to speed up allocating the small objects (such as small structs, slices, and strings) that dominate allocator time. Generating dedicated fast-path allocator routines for size classes up to 80 bytes made small allocations up to 30% faster and improved overall performance in allocation-heavy programs. Together with a ~30% reduction in baseline cgo call overhead in Go 1.26, these improvements make Go programs faster and leaner out of the box.

Go’s approach to security spans the entire lifecycle of software: providing safe APIs by design, preparing cryptography for the future, and actively defending the live ecosystem as new threats emerge.

To defend against store-now, decrypt-later attacks and support the industry’s accelerating timelines for quantum readiness, Go has continued expanding its post-quantum cryptography support. Go 1.26 enabled hybrid post-quantum key exchanges (SecP256r1MLKEM768 and SecP384r1MLKEM1024) by default in crypto/tls and added the crypto/hpke package (implementing RFC 9180 Hybrid Public Key Encryption, including post-quantum hybrid KEMs). Go 1.27 followed up with the new crypto/mldsa package, implementing the FIPS 204 post-quantum ML-DSA signature standard and integrating it into crypto/x509 and crypto/tls.

At the same time, we’ve continued hardening the standard library and runtime against subtle classes of vulnerabilities. Most key generation and signing functions across Go’s crypto/... packages now unconditionally draw from a secure system randomness source, closing off a classic footgun where non-cryptographic readers were accidentally passed in. Under the hood, Go 1.26 also added 64-bit heap base address randomization to harden cgo binaries and introduced the experimental runtime/secret package for eagerly erasing sensitive cryptographic temporaries from registers, stack frames, and the heap.

Securing Go deployments also requires rapid vulnerability and incident response in a fast-moving threat landscape. From the Go vulnerability database and govulncheck to our release infrastructure, we’ve invested heavily in ecosystem defense. In October, that preparation was put to the test during the eMudhra certificate key disclosure incident, when eight intermediate TLS and code-signing certificates chaining to a widely trusted root CA were discovered to use trivially weak private keys. Because Linux lacks a uniform OS-level certificate revocation mechanism, Go’s built-in TLS verifier is the frontline defense for millions of Linux services. Within seven and a half hours of initial notification, the Go Security team shipped a targeted block in our first-ever URGENT track security release (Go 1.27.3 and Go 1.26.10) alongside an updated Go vulnerability database entry so govulncheck could flag affected binaries, giving Go users everything they needed to protect their deployments before the weak keys were publicly disclosed the next morning.

Go has always been more than a compiler and standard library: it is an end-to-end platform for software engineering. Over the past year, our work in golang.org/x/tools, the gopls language server, vscode-go, and pkg.go.dev has focused on making that platform even more productive for both human developers and AI coding assistants.

In last fall’s Go Developer Survey, the single biggest challenge developers reported was ensuring their code follows best practices and current Go idioms. As Go evolves while standing by its compatibility promise, older ways of writing code continue to work alongside newer, clearer, or faster alternatives, creating a natural drift in idioms over time. That drift has been compounded by AI coding assistants, which gravitate toward the older patterns that dominate their training data.

Go 1.26 tackled this with a complete overhaul of the go fix command, returning the long-dormant tool to its pre-Go 1.0 roots to apply dozens of automatic modernizers across entire codebases. What gofmt did for stylistic consistency, modernizers aim to do for i