Installed Go 1.26 but Can’t Use Its New Features? Inside the go mod init Downgrade Debate

Go 1.26 go.mod init default version change

When go mod init is executed with Go 1.26, the generated go.mod contains go 1.25 (or go 1.N-2 for release candidates). This causes compilation errors for new language features that require Go 1.26, e.g.:

./main.go:5:14: new(42) requires go1.26 or later (-lang was set to go1.25; check go.mod)

“new(42) requires go1.26 or later (-lang was set to go1.25; check go.mod)”

go run

does not enforce the go version declared in go.mod, so it succeeds with the same source.

Core‑team rationale (Issue #74748, contributors dmitshur and mvdan):

Go’s maintenance policy supports the two most recent major releases (1.26 and 1.25 at the time of release).

A library published immediately after 1.26 with go 1.26 would break downstream users still on the supported 1.25.

Defaulting go.mod to the previous major version acts as a “brake”, forcing developers to make a conscious decision to adopt the newest features.

The go directive also sets the default behavior of GODEBUG; abandoning backward compatibility should be explicit.

“The new default will never cut off any currently supported Go toolchain.” — dmitshur

“We should not encourage new Go users to adopt brand‑new language features the moment they appear, because breaking compatibility for older versions should be a carefully considered choice.” — mvdan

Community objections (Issue #77653)

Violates the “principle of least surprise”: users expect new syntax to work out‑of‑the‑box after go mod init.

~99 % of go mod init invocations create private projects, micro‑services, scripts, or toys; the downgrade penalizes the majority for a small number of public library maintainers.

Since Go 1.21, GOTOOLCHAIN=auto automatically downloads the required compiler version, rendering the downgrade unnecessary.

The downgrade only blocks language‑level features; new standard‑library functions introduced in 1.26 still cause downstream 1.25 builds to fail.

“Public module maintainers need to consider compatibility, but why should millions of ordinary application developers pay the price for a few core open‑source libraries?”

“go 1.25 only blocks language‑level features. If a module built with go 1.26 uses a new standard‑library function, downstream 1.25 users will still fail to compile.” — rittneje

Technical work‑arounds

Run both commands after creating a new module: go mod init mymodule && go get go@latest Define a shell alias that runs go mod init and then edits the go directive to the current toolchain version:

alias gomodinit='f() { go mod init "$1" && go mod edit -go=$(go env GOVERSION | sed "s/go//"); }; f'

Governance note

Ian Lance Taylor responded to the debate by stating that the team will not revisit the decision without new information, emphasizing a principle of avoiding endless reconsideration of settled choices.

“We have a principle that once we make a decision, we won’t revisit it unless there is new information. Otherwise we would be stuck in an endless loop of reconsideration.”