{"id":128,"date":"2026-04-20T13:02:11","date_gmt":"2026-04-20T13:02:11","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/golang-generics-three-patterns-i-actually-use\/"},"modified":"2026-04-20T13:02:11","modified_gmt":"2026-04-20T13:02:11","slug":"golang-generics-three-patterns-i-actually-use","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/golang-generics-three-patterns-i-actually-use\/","title":{"rendered":"Go generics: the three patterns I actually use"},"content":{"rendered":"

Confession: when Go 1.18 shipped generics in early 2022, I read the release notes, wrote a toy Map[T, U]<\/code> helper, and then went right back to interface{}<\/code> for another year. I wasn’t being stubborn. I just couldn’t point at anything in my day job where generics would make the code clearly better.<\/p>\n

Four years later my position is different, but not because I suddenly fell in love with type parameters. I found three specific patterns where Go generics actually pay their rent, and about five patterns where they quietly make my code worse. This post is the honest list.<\/p>\n

If you’ve been reading Go posts where someone wraps every helper in a [T any]<\/code> and calls it progress, this isn’t one of those. I’ll show the patterns I actually ship, with the old interface{}<\/code> version next to the new one so you can see what changes and what doesn’t.<\/p>\n

Pattern 1: typed containers, the feature’s clearest win<\/h2>\n

Before 1.18, if I wanted a set in Go, I wrote a map[string]struct{}<\/code> and moved on. If I needed one for ints too, I either duplicated the code or reached for map[interface{}]struct{}<\/code> and learned to live with type assertions. Neither was great.<\/p>\n

Here’s the old version:<\/p>\n

\/\/ Pre-generics set, specialised for strings.\ntype StringSet map[string]struct{}\n\nfunc (s StringSet) Add(v string)      { s[v] = struct{}{} }\nfunc (s StringSet) Has(v string) bool { _, ok := s[v]; return ok }\n<\/code><\/pre>\n
And the generic one I actually use now:<\/p>\n
type Set[T comparable] map[T]struct{}\n\nfunc NewSet[T comparable](xs ...T) Set[T] {\n    s := make(Set[T], len(xs))\n    for _, x := range xs {\n        s[x] = struct{}{}\n    }\n    return s\n}\n\nfunc (s Set[T]) Add(v T)      { s[v] = struct{}{} }\nfunc (s Set[T]) Has(v T) bool { _, ok := s[v]; return ok }\n<\/code><\/pre>\n
Three things I care about here. comparable<\/code> is the right constraint for a map key and the compiler enforces it. There’s zero boxing or type assertion at the call site. And I write this type once and it works for my string IDs, int64 primary keys, and custom struct keys. The readability cost is tiny because the set pattern is already familiar.<\/p>\n
I use the same shape for typed priority queues and bounded ring buffers. Containers are the clearest win generics gave Go, and the standard library agrees: the slices<\/code><\/a> and maps<\/code><\/a> packages added in 1.21 are exactly this pattern at scale.<\/p>\n
Pattern 2: thin data helpers, not clever ones<\/h2>\n
My second pattern sits one level up from containers: tiny generic helpers over slices that I keep reaching for.<\/p>\n
Before:<\/p>\n
\/\/ I wrote something like this in every service.\nfunc FirstUser(users []User, match func(User) bool) (User, bool) {\n    for _, u := range users {\n        if match(u) {\n            return u, true\n        }\n    }\n    return User{}, false\n}\n<\/code><\/pre>\n
After:<\/p>\n
func First[T any](xs []T, match func(T) bool) (T, bool) {\n    for _, x := range xs {\n        if match(x) {\n            return x, true\n        }\n    }\n    var zero T\n    return zero, false\n}\n<\/code><\/pre>\n
This looks small, but I’d written maybe eight versions of it across services before 1.18. The generic First<\/code> lives in one place, I import it from our internal xslices<\/code> package, and every team uses the same signature. The trick is keeping these helpers thin: single purpose, no nested callbacks, no early-return cleverness. Once a helper grows past fifteen lines, I stop and ask whether it should be a method on a real type instead.<\/p>\n
For longer operations, the standard library’s slices.IndexFunc<\/code><\/a> and its neighbours cover most of what I used to write by hand. When Go 1.23 added range-over-func iterators<\/a>, some of my homegrown helpers became one-liners, which was a genuinely satisfying diff.<\/p>\n
Pattern 3: functional-ish adapters at service boundaries<\/h2>\n
This is the one that took me longest to trust.<\/p>\n
A typical service I work on fetches rows from Postgres, transforms them, and hands them to an HTTP handler. The transformation step used to be a tower of nested for-loops. It now looks like this:<\/p>\n
type Mapper[In, Out any] func(In) Out\n\nfunc MapSlice[In, Out any](xs []In, f Mapper[In, Out]) []Out {\n    out := make([]Out, len(xs))\n    for i, x := range xs {\n        out[i] = f(x)\n    }\n    return out\n}\n<\/code><\/pre>\n
Used:<\/p>\n
dtos := MapSlice(rows, func(r Row) RowDTO {\n    return RowDTO{ID: r.ID, Name: r.Name, Price: r.PriceCents \/ 100}\n})\n<\/code><\/pre>\n
I used to feel guilty about this, because Go’s orthodoxy is “just write the for-loop”. The for-loop is fine. But when the transformer function is pure and obvious, MapSlice<\/code> reads better than out := make([]RowDTO, 0, len(rows))<\/code> followed by a loop, and it nudges me to write small testable Mapper<\/code> functions instead of inlining mapping logic inside handlers.<\/p>\n
One rule I keep: no more than two type parameters per helper, and no constraints beyond any<\/code>, comparable<\/code>, or the built-in ordered types. The moment I want a method set in the constraint, I reach for a plain interface instead. Generics aren’t the only tool in Go and they shouldn’t pretend to be.<\/p>\n
The pattern I quietly stopped using<\/h2>\n
Here’s the one I got wrong early: wrapping a helper in generics just in case I needed it later.<\/p>\n
\/\/ Don't. This helper only ever takes user IDs.\nfunc LoadRecord[T any](ctx context.Context, id T) (*Record, error) {\n    row := db.QueryRow(ctx, "select * from records where id = $1", id)\n    \/\/ ...\n}\n<\/code><\/pre>\n
If every call site passes a string<\/code> user ID, the [T any]<\/code> isn’t earning its keep. It adds a tiny mental tax on every reader (“what types does this accept? do I need a constraint?”) without buying anything. I’ve since ripped this kind of thing out of three services and the code got shorter and clearer.<\/p>\n
The fix is simple: keep the helper concrete until a second caller with a different type forces your hand. People quote the rule of three for refactoring; for generics I’d lower it to two. One specialised function is not a problem. Two is a gentle nudge to think about whether a type parameter fits.<\/p>\n
Constraints I wish I’d learned on day one<\/h2>\n
Generics in Go aren’t only [T any]<\/code>. Three constraints pulled their weight for me:<\/p>\n