Go: Support for Generic Methods
Go’s plan to add generic methods to its type system is prompting renewed debate over the language’s design philosophy and pace of change. Many developers welcome the feature as closing a long-standing gap—especially compared to languages like Java, Rust, and TypeScript—while critics argue it erodes Go’s hallmark simplicity and readability. The exchange also revisits Go’s history of initially downplaying needs such as generics, modules, and richer error handling, and whether later reversals reflect healthy evolution or poor initial design choices.
Feature: Generic Methods in Go
- Many welcome generic methods as closing a major ergonomics gap in Go’s generics.
- Common use cases mentioned: data access methods, cleaner library APIs, avoiding awkward package-level generic functions.
- Some are excited to refactor existing libraries; others note it makes Go feel more familiar to users of other typed languages.
Design Philosophy & “Simplicity” Debate
- One camp sees this as Go slowly adding features it previously implied weren’t needed, likening the evolution to Java’s long path (generics, enums, better error handling).
- Another camp argues Go always acknowledged generics were needed, just “not yet,” with care for backward compatibility and implementation complexity.
- Critics complain that the Go community often defends current limitations as “philosophy,” then later rewrites history when features are added.
- Some view generics (and now generic methods) as a win for clarity versus prior workarounds (codegen,
interface{}, reflection). - Others lament a “sad day” where simplicity loses and the language becomes harder to read, noting new features aren’t really “optional” once widely used.
Community & Process Frictions
- Several comments criticize Go leadership for:
- Dismissing early requests (generics, modules, better error handling), then eventually adopting them.
- Overprioritizing backward compatibility and minimalism at the cost of modern type-system features.
- Others defend the slow, incremental approach as a strength, preferring Go’s stability and small core over rapid feature accretion like C++ or Rust.
Technical Limitations & Open Questions
- Generic methods won’t fulfill all expectations: they currently cannot satisfy interfaces because generic interface methods are not supported.
- This blocks certain abstractions (e.g., fully generic “monad-like” interfaces).
- The proposal text itself admits uncertainty about how to implement generic methods on interfaces efficiently; reflection-based approaches are discussed but criticized as too slow.
- Future evolution on generic interfaces is left as possible but explicitly unresolved.