Go 1.27's Generic Methods Change How I Write Helpers

Go 1.27 generic methods let a method declare its own type parameters, something the language had blocked since generics arrived in 1.18. Released on 19 August 2026, the change moves helper logic back inside the types it belongs to. There is one real limit, and I hit it fast: a generic method still cannot satisfy an interface.

The Go 1.27 release notes cover the lot. This is the bit that rewrote code I keep copying between projects.

What generic methods actually change

Before 1.27, type parameters lived on the type or on a free function. If you wanted a method that ranged over some arbitrary type, you either widened the receiver’s own type parameters or gave up and wrote a package-level function. So helpers drifted away from the types they described, and every project grew a util package full of orphaned generics.

Now the method carries the parameter. The standard library already leans on it. math/rand/v2 declares a method with the signature (*Rand) N[Int intType](Int) Int, generic on whichever integer type you pass, documented in the 1.27 release notes.

In my own code it looks like this:

type Cache[K comparable, V any] struct {
    m map[K]V
}

// Map now belongs on the type, with its own U.
func (c *Cache[K, V]) Map[U any](f func(V) U) []U {
    out := make([]U, 0, len(c.m))
    for _, v := range c.m {
        out = append(out, f(v))
    }
    return out
}

Before, Map had to be a free function taking the cache as an argument. Small difference on the page. Big difference in how the package reads.

The gotcha the headline skips

Here is the part that bit me. A generic method cannot satisfy an interface method. Interface methods may not declare type parameters, and the compiler will not let a generic method stand in for one.

So the moment you want that Map reachable through an interface, you are stuck. You cannot write an interface with a generic method and slot the type in. Polymorphism through an interface still means a package-level generic function that takes the value as an argument. The feature is for methods you call directly on a concrete type, not for abstraction across types. Worth knowing before you refactor an afternoon away.

encoding/json v2 is the quieter change

Go 1.27 also makes encoding/json v2 the implementation behind the standard encoding/json package. The v1 API stays and v1 behaviour is preserved, so importing encoding/json needs no migration and nothing in your existing code should shift.

The stricter defaults arrive only when you opt in with the encoding/json/v2 import path. That path rejects invalid UTF-8 strings and duplicate object member names, which is the behaviour I actually want in an API that parses untrusted input. If the new engine ever breaks something under you, GOEXPERIMENT=nojsonv2 puts the old implementation back at build time, though that escape hatch is expected to go away in a later release.

I have shipped hand-rolled duplicate-key checks into a couple of services precisely because v1 quietly accepted them. Deleting that code felt good.

Generic methods are the change I will use every week. JSON v2 is the one I will forget is even there until it silently does the right thing.