Go 1.27 banning generic methods from interfaces is the honest move

This August, Go finally shipped with generic methods. However, right after they were released, Go slapped your hand and told you all the places you couldn't use them. Everyone is angry. I don't believe they're right. ## What actually happened

Version 1.27 of Go was released on August 19, 2026. This release includes the foundation necessary to support defining methods and functions within concrete types (specifically structs) using their own type parameters. However, there is a caveat that confused people. An interface cannot implement a generic method. In fact, interfaces cannot declare any generic methods at all. To make clear why that is painful to hear, you need some context. For roughly a decade the official Go FAQ flatly said: "We do not anticipate that Go will ever add generic methods."

Later in January 2026, Proposal #77273 was filed by Go co-designer Robert Griesemer. It was accepted by May and shipped by August. A decade of "never" turned into "yes, but."

The orthogonality complaint

This is the argument posited by the angry crowd. "In Go, methods and interfaces are intended to be two sides of the same coin."

When you write a method, some interface somewhere should be able to leverage it. That is the basic social contract of this language. But if you break it for generic methods, you end up with a feature that is isolated. 😤

And the people making that complaint are not wrong. It's a real thing. At first glance, it may seem like a betrayal, a partial feature, an added element that was restricted in order not to showcase the insufficiency of the entire type system. ## Why the ban is the honest move

Now, let's take a look at the actual statement Griesemer made in the proposal. "Maybe we should reconsider this: Concrete methods are a language feature that we want for its own sake, for reasons having nothing to do with interfaces."

That statement puts everything in a new light. He isn't sorry for the limitation. He's saying the feature stands on its own without the interface plumbing. The issue is not being too lazy to write generic interface methods. It's that generic interface methods would break the runtime in ways you'd feel later. If the language allows it, people will write explicitly generic methods, even if it breaks type inference. Go doesn't allow it because "it cannot be known at compile time which of the infinite possible instantiations of concrete methods will be needed at run time". Software engineer Corentin Giauque Saubert explained the implications in simple terms. Generic interface methods "cause type erasure to fail, lead to dynamic dispatch issues, and are incompatible with reflection."

The consequences of this design decision are already apparent in the current implementation. For example, in Go 1.27, generic methods will be invisible to the reflect package, as this information is not available at runtime. Consider this for a moment. If interfaces had the ability to contain generic methods, many of the reflection-based tools that you currently use would become obsolete, or would become much more complex to implement. ## Saying no is a design decision

This is the hot take that upsets everybody. A language saying no to a feature request the community is begging for, can sometimes be a sign of strong leadership and discipline, not a failure. It could have involved interfaces with generic methods, dynamic dispatch, and everything else. This would have appeared to work perfectly in a demo but caused issues in real-life usage over time. Instead, they delivered what keeps the language easy. Concrete generic methods that compile predictably and don't poison reflection. The complaints that orthogonality is broken are true. However, orthogonality is a method, not an end. The end is a type system that a regular person can keep in their mind. Every language eventually has to make this trade-off. Do you ship the nice-looking feature that leaks abstractions throughout your entire system or do you ship the slightly uglier, but more honest feature and then just take the downsides of that? Go took the downsides. ## The takeaway

I prefer a language that says "no, that costs too much" rather than one that says "yes" and hands me the bill three releases later. The generic methods ban isn't a crippled feature. It's a boundary someone was brave enough to draw. 🙂

So here's a question: Do you perceive a programming language that includes a feature with a built-in hard limit as a weak language, or as a language that is looking out for you?