Generics on

Lesson 8: When Duplication Is Better Than Abstraction — Bad abstraction costs more than repeated code

Sun, 17 Nov 2024 00:00:00 +0000

I want to end this course with the idea I wish I’d understood at the start — not just intellectually, but in my gut. It’s this: duplication is a problem you can see. Bad abstraction is a problem you can’t see until it’s too late.

Duplicated code is visible. You grep for it, you find it, you fix it. It’s annoying, but it’s honest. Bad abstraction hides behind clean-looking code. It’s the function that requires fifteen minutes of context to understand, the type parameter that nobody knows how to satisfy, the constraint that’s technically correct but practically useless. It costs you in onboarding, in debugging, in every change that touches it for the rest of the codebase’s life.

Lesson 7: Refactoring Concrete to Generic — Start concrete, extract when proven

Fri, 25 Oct 2024 00:00:00 +0000

The advice “start concrete, extract when proven” is easy to say and surprisingly hard to follow when you’re in the middle of writing the third version of the same function. The temptation to generalize early is real. I’ve felt it. Most engineers who care about clean code have felt it.

But the cost of premature abstraction is higher than the cost of temporary duplication. A duplicated function can be removed with a search-and-replace. A bad abstraction gets built around, extended in wrong directions, and defended by sunk-cost thinking. This lesson is about how to do the refactoring correctly — waiting until the pattern is proven, then extracting it cleanly.

Lesson 6: Real-World Examples — Generics that survived code review

Wed, 02 Oct 2024 00:00:00 +0000

Lessons 1 through 5 were mostly about principles. This one is about code. Specifically, the five generic implementations I’ve used in real production systems that my teammates didn’t complain about. Each one passed code review, made it into production, and held up over time.

The pattern across all of them is consistent: the algorithm is identical regardless of the type, the duplication without generics would have been mechanical and ongoing, and the generic version is genuinely easier to read than the alternative.

Lesson 5: Anti-Patterns — Just because you can doesn't mean you should

Sun, 08 Sep 2024 00:00:00 +0000

Every powerful tool has a failure mode that looks like success. With generics, the failure mode is this: you write something that compiles, works correctly, and is impressively abstract — but your teammates can’t read it, can’t debug it, and quietly work around it. I’ve written code like that. It felt clever in the moment. It was a problem in practice.

This lesson is about the patterns that sound good and turn out badly. I’m calling them out explicitly because they’re seductive — especially if you’ve spent time in Haskell or Scala and you know what generic abstractions can look like.

Lesson 4: Interfaces vs Generics — Behavior or data shape? That's your answer

Wed, 14 Aug 2024 00:00:00 +0000

One of the most common mistakes I see in Go codebases post-1.18 is people reaching for generics when interfaces were already the right tool — and vice versa. The two features look superficially similar. Both let you write code that works with multiple types. But they’re solving different problems, and using the wrong one makes code harder to read, test, and extend.

Here’s the question I ask myself every time: Is what varies the behavior, or the data shape? That single question gets me to the right answer ninety percent of the time.

Lesson 3: Good Patterns — Generic code should be boring

Mon, 22 Jul 2024 00:00:00 +0000

The best generic code I’ve ever written looks like the worst. No clever type wizardry, no five-level constraint hierarchies — just a function that clearly does one thing, works for any type that makes sense, and disappears into the background of a codebase. When someone reads it two years later and immediately understands it, that’s a win.

This lesson is about the patterns where generics genuinely shine. These are the ones that survived code review, that made the team’s lives measurably better, and that I’d reach for again without hesitation.

Lesson 15: GATs — Generic associated types explained

Fri, 12 Jul 2024 18:00:00 +0000

GATs (Generic Associated Types) took seven years from proposal to stabilization. That’s not because Rust’s team is slow — it’s because GATs are genuinely hard to get right, and they unlock patterns that were previously impossible without unsafe code or painful workarounds. When they finally landed in Rust 1.65, I immediately rewrote a chunk of a database abstraction layer that had been haunting me for months.

The one-liner: GATs let associated types have their own generic parameters, including lifetimes.

Lesson 14: Const Generics — Types parameterized by values

Wed, 10 Jul 2024 15:30:00 +0000

Before const generics landed (Rust 1.51), working with arrays was painful. You couldn’t write a function that accepted [T; N] for any N. The standard library had trait implementations for arrays up to size 32 — manually written, one per size. Need [u8; 33] to implement Debug? Too bad. That era is over, and honestly, const generics are one of the most underappreciated features in modern Rust.

Instead of parameterizing types by other types, you parameterize them by values. An array’s size, a buffer’s capacity, a matrix’s dimensions — baked into the type system at compile time.

Lesson 13: Monomorphization — How generics become fast

Sun, 07 Jul 2024 11:45:00 +0000

“Zero-cost abstractions” is Rust’s battle cry. But what does that actually mean for generics? How does Vec<i32> and Vec<String> both exist without runtime overhead? The answer is monomorphization — the compiler generates a separate, specialized copy of your generic code for each concrete type used. You write it once, the compiler duplicates it for each type, and the result runs as fast as hand-written specialized code.

This is brilliant. It’s also a double-edged sword. And understanding the mechanism changes how you design generic APIs.

Lesson 12: Operator Overloading with Traits — Making your types feel native

Thu, 04 Jul 2024 20:15:00 +0000

I was building a linear algebra library and got tired of writing vector_a.add(&vector_b) everywhere. It looked ugly. It read poorly. Math should look like math — a + b, not a.add(&b). In Rust, operator overloading isn’t some dark magic — it’s just trait implementation. Every operator maps to a trait in std::ops, and implementing that trait makes the operator work on your type.

The `Add` Trait

The + operator desugars to a call to Add::add:

Lesson 11: Essential Std Traits — Iterator, Display, From, Default

Tue, 02 Jul 2024 08:30:00 +0000

There’s a tier list of Rust traits. Some you’ll implement once in your career. Some you’ll implement weekly. And then there are the ones you’ll implement so often they become muscle memory — Display, From, Default, Iterator. These four (plus a few friends) are the backbone of idiomatic Rust. If you internalize them, your types will feel native. If you skip them, your types will feel like second-class citizens in the ecosystem.

Lesson 2: Type Parameters and Constraints — Teaching the compiler what you mean

Mon, 01 Jul 2024 00:00:00 +0000

The hardest part of learning Go generics isn’t the concept — it’s the syntax. The first time I read a function signature like func Keys[K comparable, V any](m map[K]V) []K, I did a double-take. It looks like someone snuck type annotations from another language into Go. But once it clicks, it’s actually pretty elegant — every piece is there for a reason.

This lesson is about understanding type parameters and constraints deeply enough that you can write them yourself without copying from examples. That’s the threshold that separates “I’ve used generics” from “I understand generics.”

Lesson 10: Orphan Rules and the Newtype Workaround — Coherence in practice

Sun, 30 Jun 2024 17:55:00 +0000

Picture this: you’re using two crates — serde and some db_client crate. You want to implement serde::Serialize for db_client::Row. Sounds reasonable. You write the impl, and the compiler slaps you: “only traits defined in the current crate can be implemented for types defined outside of the current crate.” Welcome to the orphan rules.

My first reaction was frustration. My second reaction, after dealing with diamond dependency problems in C++ for years, was “oh, this is actually protecting me.”

Lesson 9: Blanket Implementations — Implementing for all T

Fri, 28 Jun 2024 10:20:00 +0000

The moment blanket implementations clicked for me, I felt like I’d been handed a cheat code. You write impl<T: Display> ToString for T and suddenly every single type that implements Display automatically gets ToString. One line of implementation logic, infinite types covered. This is how the standard library builds massive capability trees from small pieces.

What’s a Blanket Implementation?

A blanket implementation implements a trait for all types matching a bound, rather than for a specific type:

Lesson 8: Object Safety — Why some traits can't be dyn

Tue, 25 Jun 2024 13:40:00 +0000

The first time I got the error “the trait Clone cannot be made into an object,” I stared at it for a solid minute. Clone is one of the most fundamental traits in Rust. How can it not work with dyn? The answer is object safety — a set of rules that determine which traits can be used as trait objects. It’s one of those things that seems arbitrary until you understand why the rules exist.

Lesson 7: dyn Trait — Runtime polymorphism and its cost

Sun, 23 Jun 2024 19:15:00 +0000

Every Rust programmer hits this wall eventually. You have a Vec and you want to put different types in it — all implementing the same trait, but different concrete types. You try Vec<impl Trait> and the compiler says no. You try Vec<T> with generics and realize T can only be one type at a time. That’s when you discover dyn Trait, and the first real tradeoff in Rust’s type system: static dispatch vs dynamic dispatch.

Lesson 6: Supertraits — Building trait hierarchies

Fri, 21 Jun 2024 08:50:00 +0000

I had a trait called Serialize (homebrew, pre-serde days) that needed to format things as strings. I kept calling .to_string() inside default methods and wondering why the compiler complained. The type implementing my trait didn’t necessarily implement Display. The fix was obvious in hindsight — make Display a supertrait of Serialize. If you want to serialize, you must be displayable. Period.

Supertraits let you build trait hierarchies where implementing one trait requires implementing another.

Lesson 5: Associated Types vs Generic Parameters — Choosing the right tool

Wed, 19 Jun 2024 16:05:00 +0000

Here’s a question that confused me for months: why does Iterator use an associated type (type Item) instead of a generic parameter (Iterator<T>)? They look like they do the same thing. They kinda do. But the choice between them changes your entire API’s ergonomics, and picking wrong leads to annoying code downstream.

The short answer: associated types mean “one implementation per type,” generic parameters mean “many implementations per type.” But the implications are deeper than that.

Lesson 4: where Clauses — When bounds get complex

Mon, 17 Jun 2024 11:30:00 +0000

You know that moment when a function signature gets so long it wraps three times in your editor and you can’t even find the return type? I hit that wall writing a generic cache layer that needed Hash + Eq + Clone + Debug on the key, Serialize + DeserializeOwned + Clone on the value, and Display on both. The inline bounds turned my function signature into an unreadable mess.

Lesson 3: Trait Bounds — Constraining generic types

Fri, 14 Jun 2024 21:10:00 +0000

I once wrote a generic function that looked perfectly reasonable — accepted any T, did some work, returned a result. It compiled. Then I tried to actually use it with a type that didn’t have Clone, and suddenly the compiler was screaming at me with errors pointing at the function internals rather than the call site. That’s backwards. The fix? Trait bounds. Declare what you need upfront so the errors land where they belong.

Lesson 2: Default Implementations and Selective Overrides — Don't repeat yourself

Wed, 12 Jun 2024 14:45:00 +0000

Here’s something that bugged me when I first started with traits: I had six different types all implementing the same trait, and five of them had identical method bodies. I was copying the same three lines into five impl blocks like a human xerox machine. There had to be a better way.

There is. Default implementations.

The Basics

A trait can provide a default body for any of its methods. Implementors can then choose to override it — or just accept the default:

Lesson 1: Trait Fundamentals — Defining shared behavior

Mon, 10 Jun 2024 09:22:00 +0000

I spent my first month in Rust writing impl blocks that looked suspiciously like Java interfaces. Copy-paste, copy-paste, tweak one method, ship it. Then I hit a wall — a refactor where I needed to swap out a storage backend, and every single call site had hardcoded the concrete type. That’s when traits stopped being “a feature I should learn” and became “the thing saving me from rewriting 4,000 lines.”

Lesson 1: What Generics Solve in Go — Remove duplication without hiding intent

Fri, 07 Jun 2024 00:00:00 +0000

I spent two years writing Go before generics shipped in 1.18, and I’ll be honest — I didn’t miss them at first. Go’s simplicity felt like a feature. Then I found myself maintaining a codebase with six nearly-identical sort functions, a MinInt, MinFloat64, MinInt64, and a comment that said “do not touch, generated.” That’s when I started caring.

Generics in Go aren’t a revolution. They’re a targeted fix for a specific, real pain point: you had to either use interface{} and lose type safety, or repeat yourself across every concrete type you cared about. Neither option aged well.