How do generics (Go 1.18+) change API and library design? Where would you use or avoid them?

Question

Accepted Answer

// Before generics — needed separate functions or interface{} + reflection
func MapInts(s []int, f func(int) int) []int {
    result := make([]int, len(s))
    for i, v := range s { result[i] = f(v) }
    return result
}

// With generics — works for any type
func Map[T, U any](s []T, f func(T) U) []U {
    result := make([]U, len(s))
    for i, v := range s { result[i] = f(v) }
    return result
}

// Generic constraint
type Number interface {
    int | int64 | float64
}

func Sum[T Number](nums []T) T {
    var total T
    for _, n := range nums { total += n }
    return total
}

// Generic repository interface
type Repository[T any, ID comparable] interface {
    FindByID(ctx context.Context, id ID) (T, error)
    Save(ctx context.Context, entity T) error
    Delete(ctx context.Context, id ID) error
} Generic collections: typed stacks, queues, sets, linked lists Functional utilities: Map, Filter, Reduce, Contains, Keys, Values Typed repository or service interfaces to avoid repeated boilerplate Type-safe event bus or pub/sub systems Constraint-based numeric or ordered operations Runtime polymorphism with interfaces is sufficient and clearer The type set is open-ended — new types should satisfy behavior via interfaces, not constraints Constraints become so complex they hurt readability more than they help You need method type parameters — Go does not support them, only function and type-level generics

How do generics (Go 1.18+) change API and library design? Where would you use or avoid them?

Generics allow writing type-safe functions and data structures that work across multiple types without code duplication or runtime reflection, but should complement rather than replace interfaces.

Scenario Questions

Follow-up Questions