Go: Support for Generic Methods
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.