Go Generics in Production: Patterns and Pitfalls for Cloud Infrastructure Code

Your cloud infrastructure codebase has fifteen near-identical retry handlers. You know this because you wrote most of them. There’s RetryHTTPClient, RetryGRPCCall, RetryDatabaseQuery, RetryS3Upload—each one a careful copy of the last, with the types swapped out and a comment at the top that says something optimistic like “TODO: consolidate these.” That comment is three years old.

This was the pre-generics bargain in Go. You accepted the copy-paste tax, or you reached for interface{} and paid a different price: runtime panics buried in type assertions, lost compile-time safety, and the peculiar joy of reading code where everything is any and nothing is knowable until production tells you otherwise. The third option was go generate—which worked, technically, the way that duct tape works technically.

Go 1.18 shipped generics. The community collectively exhaled. But infrastructure codebases are not toy examples, and the patterns that look elegant in a README have a way of turning expensive the moment they touch real complexity: a service mesh with a dozen distinct client types, a Kubernetes operator managing heterogeneous resource pools, a config parser that needs to be both flexible and auditable. The wrong abstraction here doesn’t just add lines—it adds cognitive overhead to every engineer who has to debug a cascading failure at 2 AM.

The good news is that generics, used correctly, genuinely solve the retry handler problem. The bad news is that “correctly” requires understanding where Go’s implementation makes trade-offs that aren’t visible in the type signatures.

Infrastructure code is the most demanding proving ground for these patterns—and the most instructive one.

Why Infrastructure Code Is the Ideal—and Hardest—Test for Go Generics

Infrastructure code lives at the intersection of two competing pressures: it must be generic enough to handle diverse workloads, and it must be precise enough that a wrong type assumption cascades into a production outage. That tension made pre-generics Go infrastructure codebases some of the most contorted in the ecosystem—and it makes them the most instructive proving ground for generics today.

The Interface Surface Area Problem

Consider the primitives that appear in every serious infrastructure codebase: retry logic with exponential backoff, circuit breakers tracking error rates, resource pools managing connections or goroutines, and typed configuration parsers that deserialize YAML into structured policy objects. Each of these is fundamentally parameterized by a type it doesn’t own. A retry wrapper doesn’t care whether it’s retrying an S3 put or a Kubernetes API patch—it cares about the call signature and the returned value.

Before generics, Go engineers chose between three approaches, all of them painful. The first was interface{}—now any—with type assertions scattered through calling code. Every assertion is a runtime bet that the compiler cannot validate. The second was code generation via go generate, which works but adds a build step, requires maintaining generator templates alongside business logic, and produces code that nobody wants to read during an incident at 2 AM. The third was copy-paste specialization: a RetryHTTP function here, a RetryGRPC function there, diverging silently over eighteen months until one gets a bug fix the other doesn’t.

Each approach trades one kind of pain for another. Type assertions move errors from compile time to runtime. Code generation distributes complexity into the build pipeline. Copy-paste creates maintenance debt that compounds with every new transport, every new resource type, every new team member who doesn’t know which version of the function to use.

What Generics Actually Deliver

Generics allow infrastructure primitives to be written once, typed correctly, and composed freely—without the escape hatch of any. A generic retry wrapper can return the caller’s exact type. A generic pool can enforce that only one concrete resource type flows through a given instance. A config parser can bind directly to a typed struct without reflection.

💡 Pro Tip: The productivity gain from generics in infrastructure code is not primarily about fewer lines—it is about moving type errors from Datadog alerts back to go build. That shift in error discovery time is what justifies the learning curve.

What generics do not deliver is magic. Monomorphization means the compiler generates specialized code per type, which has real implications for binary size and compilation time in large operators. Type inference reduces boilerplate but also obscures what a function actually accepts. Constraint expressiveness has hard limits that force awkward workarounds in exactly the cases infrastructure code hits most often.

Understanding those limits starts with the constraint system itself—the grammar that determines what your generic functions can actually do.

Type Constraints: The Grammar You Must Get Right First

Constraints are the type system’s contract with your generic code. Get them wrong and you either write code the compiler rejects, or—worse—write code the compiler accepts that misleads every engineer who reads it afterward. Before reaching for any generic pattern in infrastructure tooling, you need fluency with what constraints actually express.

Union Constraints vs. Interface Constraints

Go generics give you two distinct constraint forms, and confusing them is the first trap senior engineers fall into.

An interface constraint expresses behavior—the type parameter must implement certain methods:

type Identifiable interface {
    ID() string
    Region() string
}

func Register[T Identifiable](resources []T, registry map[string]T) {
    for _, r := range resources {
        registry[r.Region()+"/"+r.ID()] = r
    }
}

A union constraint (using ~T | U syntax) expresses representation—it restricts to a closed set of underlying types and enables operators on those types:

type Numeric interface {
    ~int | ~int64 | ~float64
}

func Sum[T Numeric](values []T) T {
    var total T
    for _, v := range values {
        total += v
    }
    return total
}

The ~ prefix matters. ~int64 includes any named type whose underlying type is int64—so your type Latency int64 satisfies it. Without the tilde, only the exact predeclared type matches. In infrastructure code, where you routinely define semantic types over primitives (type VCPU int, type GiB int64), forgetting ~ produces constraint satisfaction errors that look baffling until you trace the underlying type.

Union constraints do not support method calls. If you write a union constraint and then try to call a method inside the generic function, the compiler rejects it. The two forms are not interchangeable—choose based on whether you need operators or behavior.

Embedding Constraints for Composability

The standard library’s constraints package (or its predecessor via golang.org/x/exp/constraints) provides Ordered, Integer, and Float. Rather than reconstructing these, embed them:

type ScalableMetric interface {
    constraints.Ordered
    fmt.Stringer
}

func Clamp[T ScalableMetric](value, min, max T) T {
    if value < min {
        return min
    }
    if value > max {
        return max
    }
    return value
}

Embedding composes constraints cleanly and signals intent to the reader: this function works on anything that is both orderable and printable. That communicates more than a raw union would.

Constraints That Document Intent

A constraint named Numeric tells you what kinds of types qualify. A constraint named interface{ ~int | ~int32 | ~int64 | ~float32 | ~float64 | ~uint | ~uint32 | ~uint64 } tells you nothing beyond its own repetitive contents. Name your constraints to capture the semantic role, not the structural inventory.

💡 Pro Tip: Define constraints in a dedicated constraints.go file within your package. Engineers onboarding to the codebase find the complete vocabulary in one place, rather than hunting through function signatures.

Over-Constraining and Under-Constraining

Over-constraining locks callers into narrow types they have to convert around. A cache eviction function constrained to ~string when it only needs comparable forces unnecessary friction. Under-constraining with any defers errors to runtime and forfeits the compiler’s help entirely.

The test: if your function body only calls methods, use an interface constraint listing exactly those methods. If your function body uses operators (+, <, ==), use a union or embedded constraint that permits them. Match the constraint surface to the function’s actual requirements—no wider, no narrower.

With a solid constraint vocabulary established, the next section puts that foundation to work in generic data structures built specifically for the reliability and concurrency demands of cloud infrastructure code.

High-Value Patterns: Generic Data Structures for Infrastructure

Infrastructure code lives at the intersection of high throughput, strict correctness requirements, and the need for operators to understand what failed and why. Three generic patterns—a typed resource pool, a retry wrapper that preserves return types, and an explicit Result[T]/Option[T] pair—address exactly these concerns with less ceremony than their interface{}-based predecessors.

Typed Resource Pool with Bounded Concurrency

sync.Pool is designed for temporary object reuse to reduce GC pressure. It does not provide bounded concurrency, does not preserve type information, and offers no lifecycle hooks. For infrastructure work—database connection pools, cloud API client pools, gRPC channel pools—you need all three.

type Pool[T any] struct {
  sem   chan struct{}
  items chan T
  new   func() (T, error)
}

func NewPool[T any](size int, factory func() (T, error)) (*Pool[T], error) {
  p := &Pool[T]{
    sem:   make(chan struct{}, size),
    items: make(chan T, size),
    new:   factory,
  }
  for range size {
    item, err := factory()
    if err != nil {
      return nil, fmt.Errorf("pool init: %w", err)
    }
    p.items <- item
  }
  return p, nil
}

func (p *Pool[T]) Acquire(ctx context.Context) (T, error) {
  select {
  case item := <-p.items:
    p.sem <- struct{}{}
    return item, nil
  case <-ctx.Done():
    var zero T
    return zero, ctx.Err()
  }
}

func (p *Pool[T]) Release(item T) {
  <-p.sem
  p.items <- item
}

The type parameter T ensures that a pool of *s3.Client never hands you a *dynamodb.Client—a class of bug that is impossible to detect at compile time with sync.Pool. The semaphore channel enforces the bounded concurrency contract that sync.Pool explicitly disclaims. Callers get clean, context-aware acquisition with no type assertions at the call site.

Two additional properties matter in production. First, because Acquire selects on both p.items and ctx.Done(), a slow downstream service or a saturated pool never leaks goroutines—context cancellation propagates cleanly. Second, because the pool is initialized eagerly in NewPool, you discover misconfigured credentials or unreachable endpoints at startup rather than under load. Both of these behaviors require explicit engineering with sync.Pool; here they are structural consequences of the design.

Generic Retry Wrapper with Typed Return Values

Retry logic is written once per project at best, and once per package at worst. The traditional approach returns interface{} or forces callers to wrap the operation in a closure that mutates an outer variable. Generics eliminate both problems.

type RetryConfig struct {
  MaxAttempts int
  BaseDelay   time.Duration
  MaxDelay    time.Duration
}

func WithRetry[T any](ctx context.Context, cfg RetryConfig, op func(ctx context.Context) (T, error)) (T, error) {
  var (
    result T
    err    error
    delay  = cfg.BaseDelay
  )
  for attempt := range cfg.MaxAttempts {
    result, err = op(ctx)
    if err == nil {
      return result, nil
    }
    if attempt == cfg.MaxAttempts-1 {
      break
    }
    select {
    case <-time.After(delay):
      delay = min(delay*2, cfg.MaxDelay)
    case <-ctx.Done():
      var zero T
      return zero, ctx.Err()
    }
  }
  var zero T
  return zero, fmt.Errorf("after %d attempts: %w", cfg.MaxAttempts, err)
}

A real call site looks like this:

cfg := RetryConfig{MaxAttempts: 5, BaseDelay: 250 * time.Millisecond, MaxDelay: 10 * time.Second}

instance, err := WithRetry(ctx, cfg, func(ctx context.Context) (*ec2.Instance, error) {
  return client.DescribeInstance(ctx, "i-0a1b2c3d4e5f67890")
})

The compiler infers T as *ec2.Instance. No casting, no intermediate any, no chance of a runtime panic from a mismatched type assertion downstream. The exponential backoff is capped at MaxDelay using min, a standard library function available since Go 1.21, so the implementation avoids hand-rolling a common source of off-by-one errors.

Pro Tip: Wrap WithRetry with a domain-specific helper (WithCloudRetry, WithDBRetry) that bakes in the RetryConfig appropriate for that subsystem. This keeps call sites clean while preserving the generic implementation as a single source of truth. It also gives you a natural place to inject subsystem-specific error classification—distinguishing transient network errors from non-retryable authorization failures—without complicating the core retry loop.

Result[T] and Option[T] for Pipeline Stages

Cloud infrastructure pipelines—account provisioning, drift detection, compliance scanning—process resources in stages. When a stage can fail, the idiomatic Go approach of (T, error) pairs works well for single calls but becomes awkward when you need to collect results across a fan-out, pass them through channels, or store partial failures alongside successes. A value and an error cannot both be sent as a single channel message without boxing them into a struct.

type Result[T any] struct {
  Value T
  Err   error
}

func OK[T any](v T) Result[T]        { return Result[T]{Value: v} }
func Err[T any](err error) Result[T] { return Result[T]{Err: err} }

func (r Result[T]) Unwrap() (T, error) { return r.Value, r.Err }
func (r Result[T]) IsOk() bool         { return r.Err == nil }

type Option[T any] struct {
  value *T
}

func Some[T any](v T) Option[T]  { return Option[T]{value: &v} }
func None[T any]() Option[T]     { return Option[T]{} }
func (o Option[T]) IsSome() bool { return o.value != nil }
func (o Option[T]) Unwrap() T {
  if o.value == nil {
    panic("Option.Unwrap called on None")
  }
  return *o.value
}

In a fan-out stage, results flow through a typed channel:

results := make(chan Result[*ComplianceReport], len(accounts))
for _, accountID := range accounts {
  go func(id string) {
    report, err := scanAccount(ctx, id, "us-east-1")
    if err != nil {
      results <- Err[*ComplianceReport](fmt.Errorf("account %s: %w", id, err))
      return
    }
    results <- OK(report)
  }(accountID)
}

The channel type chan Result[*ComplianceReport] documents the contract. Consumers iterate without asserting types, and partial failures are collected alongside successes rather than short-circuiting the entire scan.

Option[T] addresses a distinct problem: distinguishing “the operation succeeded and returned nothing” from “the operation did not run.” In interface{}-based code, both conditions look like nil, and the distinction relies on documentation or convention. A function returning Option[*CacheEntry] makes the absence case explicit in the type signature and forces callers to check IsSome() before calling Unwrap()—a constraint that *CacheEntry alone cannot enforce.

Together, Result[T] and Option[T] eliminate two categories of silent failure that generics-free Go code routinely produces: the unchecked type assertion on an any value extracted from a channel, and the nil pointer dereference on a return value that callers assumed was always populated.

These three patterns beat their interface{}-based equivalents not because generics are philosophically superior, but because they push error classes from runtime panics into compile-time failures and eliminate the cognitive load of tracking what concrete type lives inside an any. With these primitives in place, the natural next question is what they cost—and that cost is real.

Monomorphization, Binary Bloat, and Real Performance Trade-offs

Go’s generics implementation diverges sharply from C++‘s full template specialization, and that gap has direct consequences for infrastructure code running in hot paths. Understanding the compiler’s actual strategy—GC shapes—prevents you from making performance decisions based on false assumptions.

How Go Actually Compiles Generics

Go uses GC shape stenciling rather than full monomorphization. The compiler groups type arguments by their GC shape: all pointer types share one instantiation, all int-sized types share another, and so on. This means a generic function instantiated for *Node and *Edge compiles to a single binary function, not two specialized copies.

The consequence is that pointer-receiver generics use indirect calls through an implicit dictionary of type metadata. Unlike C++, where vector<int> and vector<float> produce completely separate, inlinable code, Go’s pointer-shape generics carry a runtime dispatch cost that scales with call frequency.

Value types behave differently. A generic function over int32 and float64 produces two distinct stencils because their GC shapes differ. Those instantiations can inline aggressively and carry no dictionary overhead—they behave close to hand-written concrete functions.

This asymmetry is the single most important thing to internalize: the performance characteristics of a generic function depend entirely on whether the type arguments resolve to pointer shapes or value shapes at compile time.

Measuring the Actual Cost

Before trusting intuition, benchmark with realistic infrastructure workloads. The following benchmark isolates the three dispatch modes you encounter in practice:

package dispatch_test

import "testing"

// Concrete implementation
func sumConcrete(vals []int64) int64 {
    var total int64
    for _, v := range vals {
        total += v
    }
    return total
}

// Generic over value types - distinct GC shape, no dictionary
func sumGeneric[T int32 | int64 | float64](vals []T) T {
    var total T
    for _, v := range vals {
        total += v
    }
    return total
}

// Interface dispatch baseline
type Summer interface{ Sum() int64 }

var sink int64

func BenchmarkConcrete(b *testing.B) {
    data := make([]int64, 1024)
    for i := range data { data[i] = int64(i) }
    b.ResetTimer()
    for b.Loop() { sink = sumConcrete(data) }
}

func BenchmarkGenericValue(b *testing.B) {
    data := make([]int64, 1024)
    for i := range data { data[i] = int64(i) }
    b.ResetTimer()
    for b.Loop() { sink = sumGeneric(data) }
}

Run with -gcflags="-m" to verify inlining decisions, and -benchmem to catch hidden allocations. On a function like sumGeneric[int64], the compiler emits a stencil identical to sumConcrete—the benchmark confirms zero overhead. Add a third benchmark instantiating the same function over a pointer type to see the dictionary cost materialize directly in the numbers.

Note: Use go build -v ./... combined with nm on the output binary to count instantiated symbols. A generic function instantiated across five pointer types still produces one symbol; across five distinct value types it produces five. Watch the second case in large codebases with many type parameters—binary size grows linearly with distinct value-shape instantiations.

Where Generics Hurt in Latency-Sensitive Paths

The dictionary mechanism becomes measurable when a generic function over pointer types sits inside a tight loop processing thousands of events per second—common in event pipeline processors, rate limiters, and metrics aggregators. Each call dereferences the implicit type dictionary, defeating branch predictors and increasing instruction-cache pressure.

In those paths, the correct decision is to drop back to concrete types and use generics at the boundary—the constructor or factory—where call frequency is negligible:

// Generic factory: called once at startup, no hot-path cost
func NewProcessor[T MetricEvent](cfg ProcessorConfig) *ConcreteProcessor {
    return &ConcreteProcessor{bufferSize: cfg.BufferSize}
}

// Concrete hot path: no generics, no dictionary, full inlining
type ConcreteProcessor struct{ bufferSize int }

func (p *ConcreteProcessor) Process(e MetricEvent) error {
    // inlineable, predictable, measurable
    return nil
}

This pattern—generic construction, concrete execution—captures most of the ergonomic benefit of generics while preserving the performance profile of hand-written code. It also keeps the hot path auditable: a reviewer can confirm inlining decisions without reasoning about which GC shape the compiler resolved.

Binary bloat is real but secondary to dispatch overhead for most infrastructure services. A service binary growing by 2 MB from generic data structure instantiations is rarely the bottleneck; an extra indirect call on every metric ingestion event is. Profile before optimizing either.

Type inference interacts with these decisions in non-obvious ways, particularly when the compiler’s inferred type argument resolves to a pointer shape you didn’t anticipate—which is the failure mode we examine next.

Type Inference in Practice: Where It Helps and Where It Hides Bugs

Go’s type inference eliminates annotation noise at call sites, making generic code feel as natural as writing concrete functions. For infrastructure engineers reading and reviewing code under time pressure, that reduction in syntactic clutter matters. But inference operates on rules that occasionally produce types you did not intend—and unlike a runtime panic, those surprises can travel silently through your system until they surface at a serialization boundary or an API call.

Where Inference Works for You

The common case is straightforward: when you call a generic function with a typed argument, Go infers the type parameter from the argument.

func Get[T any](cache map[string]T, key string) (T, bool) {
    v, ok := cache[key]
    return v, ok
}

regionCache := map[string]string{
    "us-east-1": "Virginia",
    "eu-west-1": "Ireland",
}

// T is inferred as string—no annotation required
region, ok := Get(regionCache, "us-east-1")

This is inference doing its job: the type is unambiguous, the annotation would be redundant, and removing it improves readability.

Where Inference Fails or Misleads

The failure modes are less obvious. Consider a function that returns only a generic type with no input to infer from:

func Zero[T any]() T {
    var z T
    return z
}

// Does not compile: cannot infer T
// threshold := Zero()

// Must be explicit
threshold := Zero[int64]()

A subtler case occurs with untyped constants. Go infers the default type for numeric literals (int, float64) rather than the type you likely want in infrastructure code:

func Scale[T int32 | int64 | float64](value T, factor T) T {
    return value * factor
}

// Inferred as int, which satisfies neither int32 nor int64—compile error
// result := Scale(1000, 2)

// Explicit parameter prevents ambiguity
result := Scale[int64](1000, 2)

The untyped constant 1000 defaults to int, which is not in the constraint. The compiler catches this, but only because the constraint is tight. With any or a looser constraint, inference silently locks in a type that breaks downstream—for example, when marshaling a metric value to a Prometheus label.

💡 Pro Tip: In functions where the inferred type drives serialization, network encoding, or numeric precision, add explicit type parameters. They serve as documentation and as a contract that code review can verify without running the code.

Tooling Support

go vet catches some inference-related issues, but staticcheck and golangci-lint with the typecheck and gocritic analyzers cover the gaps. Add a lint rule to your CI pipeline that flags untyped numeric literals passed to generic arithmetic functions—it surfaces the int vs int64 class of bug before it reaches a staging environment.

The next section examines the pitfalls that appear not at compile time but in production: interface boxing inside generic wrappers, unexpected heap allocations, and constraint definitions that permit more than you intended.

Pitfalls That Will Burn You in a Real Codebase

Generics in Go are not simply “templates from other languages.” The type system enforces constraints that catch experienced engineers off guard, particularly when generic code interacts with interfaces, reflection, and nil semantics. These are the failure modes that produce cryptic compiler errors on Monday morning or subtle runtime panics that only appear under production load.

You Cannot Add Methods to Instantiated Generic Types

Go prohibits defining methods on instantiated generic types outside the original package. If you define type Cache[K, V any] struct { ... } and attempt to attach methods to Cache[string, string] in a consumer package, the compiler refuses. This forces you to compose rather than extend, which is often the right call anyway—but it surprises engineers who reach for embedding as a quick extension mechanism. The workaround is to define the methods on the generic type itself, accepting that every instantiation carries them, or to use a wrapper struct in the consumer package.

Interface Satisfaction With Generic Receivers

A generic type satisfies an interface only when its concrete instantiation does. A type Result[T any] that implements fmt.Stringer via a method on *Result[T] does not automatically satisfy Stringer when passed as a value. This is identical to standard Go pointer receiver rules, but the indirection of generics makes it easier to miss. The failure manifests as a compiler error far from the definition site, often inside a generic utility function that accepts a constrained type parameter.

Recursive Generic Types

The compiler rejects recursive generic type definitions that are not mediated by a pointer or interface. Attempting to define a tree node where the node type directly references itself as a type argument produces a stack overflow during compilation—not at runtime, but in the compiler itself, which produces an error message that does not obviously point to the recursion. The fix is always to introduce a pointer: type Node[T any] struct { Left *Node[T] } rather than Left Node[T].

Nil Interface vs. Nil Pointer Through Generic Wrappers

The classic nil interface trap—a typed nil pointer stored in an interface variable compares unequal to nil—becomes significantly harder to reason about inside generic wrappers. A function returning error that internally constructs a generic Result[*MyError] and returns it as an interface can return a non-nil error containing a nil pointer. The generic layer adds an indirection that breaks the visual inspection heuristics engineers rely on.

💡 Pro Tip: When a generic function returns an interface type, add an explicit if result == nil { return nil } check before the return. Do not rely on the zero value of a type parameter being the correct nil for the interface.

These pitfalls share a common root: generics are not syntax sugar over interface{}. They participate fully in Go’s type system, which means all of Go’s type system edge cases apply. Understanding that foundation makes the adoption strategy far more tractable—which is exactly where we turn next.

Adoption Strategy: Introducing Generics Without Breaking Your Team

Generics adoption fails when teams treat it as a syntax upgrade rather than a design decision. The engineers who get it right start narrow, establish review norms early, and treat generic API surfaces as a commitment—not an experiment.

Start With the Highest-ROI Refactors

Not every duplicated function justifies a type parameter. Scan your codebase for these high-signal candidates first:

• Typed collection wrappers — ResourceList, NodeSet, or any struct that wraps a slice or map and duplicates methods across multiple concrete types
• Retry and circuit-breaker utilities — these almost always contain interface{} casts or duplicate implementations per return type
• Configuration validators — pipelines that apply the same validation logic to structurally similar but type-distinct config objects

Avoid refactoring error-handling paths, context propagation utilities, or anything that sits on a hot path until you have profiling data from the generic version in a staging environment. The ROI there is low and the risk is real.

Code Review Heuristics

Approve a generic abstraction when: the same logical operation appears across three or more concrete types, the constraint is structurally meaningful rather than artificially broad, and the call sites become simpler—not just shorter.

Reject it when the type parameter appears only once, when the constraint is effectively any, or when understanding the function requires reasoning about three layers of indirection. The generic version of a function should be easier to read than the alternatives, not harder.

💡 Pro Tip: Add a one-line comment above each exported generic type explaining what the constraint enforces and why. Engineers unfamiliar with parametric types will read the constraint definition and assume it’s more restrictive or more permissive than it is. The comment bridges that gap faster than documentation.

API Stability and Versioning

Exported generic types are part of your public API. A constraint change is a breaking change—even if the underlying logic is identical. Version generic packages deliberately: if you export Cache[K, V] in a shared infrastructure library, treat any modification to K’s constraint with the same discipline you’d apply to removing a method from an interface.

Teams that establish these norms before the first generic PR lands avoid the painful retrofit that comes from discovering constraint mismatches across a monorepo six months later.

The patterns and pitfalls covered throughout this guide compound once generics appear in shared libraries. The final consideration is whether the trade-offs examined here justify adoption for your specific infrastructure domain.

Key Takeaways

• Reach for generics when you have three or more concrete duplicates with identical logic—not before; premature generalization creates unmaintainable constraints.
• Benchmark generic hot paths against concrete-typed equivalents using Go’s GC shape model to predict where you’ll pay indirect dispatch costs.
• Export constraint interfaces as named types so callers can extend them—this is the primary API surface generics add to your public packages.
• Add explicit type parameters at call sites wherever inference would obscure intent; treat them as compiler-checked documentation.