Go 1.27 Release Notes - The Go Programming Language

Go 1.27 Release Notes

Introduction to Go 1.27

The latest Go release, version 1.27, arrives in August 2026, six months after Go 1.26.<br>Most of its changes are in the implementation of the toolchain, runtime, and libraries.<br>As always, the release maintains the Go 1 promise of compatibility.<br>We expect almost all Go programs to continue to compile and run as before.

Changes to the language

Go 1.27 now supports generic methods:<br>a method declaration may declare its own<br>type parameters.<br>This widely anticipated change allows adding generic functions within<br>the namespace of a particular data type where before one had to declare<br>such functions with a scope of the entire package.<br>As an example, math/rand/v2 now also declares a generic method with signature<br>(*Rand) N[Int intType](Int) Int, whereas previously it had just a<br>generic function N[Int intType](Int) Int (see below for details).<br>Note that methods of interfaces may not declare<br>type parameters nor can interface methods be implemented by generic methods.

A key in a struct literal may now be any<br>valid field selector for the struct type, not just a<br>(top-level) field name of the struct.

Function type inference has been generalized to apply in all<br>contexts where a generic function is assigned to a<br>variable of (or converted to) a matching function type.

Tools

Response file (@file) parsing is now supported for the compile, link, asm, cgo, cover, and pack tools.<br>The response file contains whitespace-separated arguments with support for single-quoted and double-quoted strings, escape sequences, and backslash-newline line continuation.<br>The format is compatible with GCC&rsquo;s response file implementation to ensure interoperability with existing build systems.

Go command

The go command no longer has support for the bzr version control system.<br>It will no longer be able to directly fetch modules hosted on bzr servers.

GODEBUG

Starting with Go 1.27, the go command now recognizes a GODEBUG setting<br>for which support was removed (such as asynctimerchan, see below) if it appears in go.mod<br>files (godebug entries) and .go source files (//go:debug comments).<br>It accepts these settings if they are set to the final default value established before<br>the setting was removed.<br>If they are set to an old value, the go command will fail.<br>This change is in the spirit of the Go 1 compatibility guarantee<br>and allows existing programs that set supported GODEBUG settings to continue to<br>build and run without changes even when the respective setting support has been removed.

go test

go test now invokes the stdversion vet check by default.<br>This reports the use of standard library symbols that are too new<br>for the Go version in force in the referring file,<br>as determined by go directive in go.mod and build tags on the file.

go test -json now annotates "Action":"output" lines with an optional<br>new field "OutputType", specifying the type of output.<br>Currently, the possible values include &ldquo;error&rdquo;, &ldquo;error-continue&rdquo;, and &ldquo;frame&rdquo;.<br>See cmd/test2json help for details.

go doc

The go doc command now supports package@version syntax, such as<br>go doc example.com/pkg@v1.2.3.

The go doc command now accepts the -ex command-line option to<br>list executable examples of the given package or symbol.<br>When an example name is passed on the command line (such as<br>go doc bytes.ExampleBuffer), go doc now prints the example source<br>code along with comments.

go fix

The go fix command contains several new modernizers (atomictypes, embedlit, slicesbackward, and unsafefuncs).

The existing fmtappendf analyzer was removed due to stylistic concerns.

The existing waitgroup analyzer was renamed to waitgroupgo to avoid ambiguity.

go mod tidy

For modules specifying go 1.27 or later in their go.mod file, go mod tidy<br>now automatically merges duplicate require blocks. This ensures the file<br>maintains a clean, standard structure containing at most two require blocks:<br>one for direct dependencies and one for indirect dependencies.

Existing comment blocks attached to dependencies are preserved during this<br>consolidation. If a comment block is associated with a mixed set of directives<br>(containing both direct and indirect dependencies), the comment block is merged<br>and attached to the new direct dependency block.

Previously, if a go.mod file accumulated multiple disjoint require blocks<br>(often due to manual edits, unresolved Git merge conflicts, or legacy upgrades)<br>go mod tidy would leave the extra blocks intact or inadvertently create new<br>ones. The tool now strictly enforces the two-block layout, consolidating<br>disparate requirements into their respective blocks and cleaning up the<br>structure of the module file automatically.

Trace

go tool trace&rsquo;s -http command-line option now restricts the listen<br>address to localhost when passed only a port (e.g., -http=:6060).<br>This change makes go tool trace consistent with the behavior of<br>go tool...