Go 1.27 gives methods type parameters, and one line about interfaces decides who benefits

The standard library's own showcase shows what adoption costs. math/rand/v2 now also declares a method with the signature `(*Rand) N[Int intType](Int) Int`, where the package previously had only a package-scope generic function `N` with that same signature ^[3]. The typed methods the generic one duplicates, `Int32N`, `Int64N` and `IntN`, are still exported, and the release announcement says it left the unsigned variants out of its listing for brevity ^[4]. Nothing was deleted, because nothing can be: the release keeps the Go 1 promise of compatibility ^[1]. Count the symbols and math/rand/v2 left this release one method wider than it entered ^[10].

The exclusion of interface methods ^[5] is the sentence that will settle most API reviews, because in Go the seam between packages is usually an interface. A parameterised method is therefore available on a concrete type and invisible to anything that abstracts over it. An invented `Store` interface with `GetInt`, `GetString` and `GetBytes` does not collapse under 1.27. What collapses is the `rand.Rand` case: a concrete type, addressed as itself, carrying a family of identically shaped methods that differ only in an integer or element type ^[2].

The inference change is quieter and probably reaches more code. It now applies wherever a generic function is assigned to a variable of, or converted to, a matching function type ^[6]. Inference runs from the destination, so it pays off where the destination type is already written down: a `[]IntFormatter` literal accepts `GenericFormatter` unadorned, as does a conversion and a send on a `chan IntFormatter` ^[7].

The struct literal rule has a review cost attached. A `Gopher` that embeds `Habitat` can now be constructed with `Burrow` set directly in the literal ^[9], since a key may be any valid field selector for the type ^[8]. My reservation is that the construction site stops recording which struct owns the field, so neither a reader nor a diff can see embedding depth from the literal.

One performance number is worth reading in both directions. Size-specialised allocation cuts small object (under 80B) allocation cost by up to 30% and moves allocation-heavy programs about 1% overall ^[11]. Divide the second by the first and small-object allocation was worth roughly 3% of runtime in those programs to begin with ^[12]. That is free, and it is not a reason to schedule an upgrade.

The rest is maintenance. `go test` runs the `stdversion` vet check by default, reporting standard library symbols newer than the Go version in force in the referring file ^[13]; `go mod tidy` consolidates duplicate `require` blocks for modules declaring `go 1.27` or later ^[14]; the `go` command has dropped `bzr` entirely ^[15]. The language change is the one that costs design time, and the cost is not in adopting it. It is in choosing which of your same-shaped method families is worth a second, permanent way to be called.