go-generics

Go Generics

Generics are a powerful but easy-to-misuse feature. The Go answer is pragmatic: write concrete code first, then generalize only when you have a real second caller.

Core Rules

1. Write concrete first. Reach for generics only when a second type actually needs the same logic.
2. If an interface already models the behavior, use the interface. Don't pile type parameters on top.
3. Prefer standard constraints (comparable, cmp.Ordered, any) over hand-rolled unions.
4. Don't over-constrain. comparable is usually enough; the narrower the constraint, the fewer callers benefit.
5. Name type parameters with a single uppercase letter (T, K, V, E) unless a longer name genuinely helps.
6. Don't use generics for interface satisfaction. func F[T io.Reader](r T) is just func F(r io.Reader).
7. Don't wrap stdlib containers "for generic convenience" unless you eliminate real duplication.

Decision Flow

Multiple types need the same logic?
├─ No  → concrete type
├─ Yes → do they share a useful interface?
│        ├─ Yes → use the interface
│        └─ No  → use generics

When NOT to Use Generics

// Premature: only ever called with int
func Sum[T constraints.Integer | constraints.Float](xs []T) T {
    var t T
    for _, x := range xs { t += x }
    return t
}

// Better
func SumInts(xs []int) int {
    var t int
    for _, x := range xs { t += x }
    return t
}

"Write code, don't design types." — Griesemer & Taylor

When Generics Pay Off

• A library function the standard library would have written generically: slices.Index, maps.Keys, slices.SortFunc.
• Concurrent-safe data structures (typed sets, ordered maps) where boxing into any would be both ugly and slow.
• Map/Reduce-style helpers that genuinely apply to many element types.

Type Parameter Naming

Name	Typical use
T	General element / first type
K	Map key
V	Map value
E	Element of a collection
R	Result of a transform