Go Turns 17 - The Go Programming Language

Common problems companies solve with Go
Stories about how and why companies use Go
How Go can help keep you secure by default
The official Go language specification
A complete introduction to building software with Go
Reference documentation for Go's standard library
Learn what's new in each Go release
Tips for writing clear, performant, and idiomatic Go code
Videos from prior events
Meet other local Go developers
Learn and network with Go developers from around the world
The Go project's official blog.
Get help and stay informed from Go
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 s