Advanced on

Lesson 10: Dependent Type Tricks — Encoding constraints in types

Mon, 22 Sep 2025 15:50:00 +0000

There’s a running joke in the Rust community: “Rust has a dependent type system, it just doesn’t know it.” And like most good jokes, there’s truth in it. Rust doesn’t have real dependent types like Idris or Agda, where types can depend on arbitrary runtime values. But with const generics, sealed constructors, and some creative type engineering, you can get surprisingly close.

This final lesson is about pushing Rust’s type system to its absolute limits — encoding constraints that most people assume you need a dependently-typed language for.

Lesson 9: Proof Witnesses — Types as proofs

Fri, 19 Sep 2025 13:22:00 +0000

The moment this clicked for me was when I was reviewing a crate that had a function signature like fn process(data: &[u8], _proof: NonEmpty<'_>). That second argument carried no data. It was zero-sized. But you could only construct it by proving — through code that the compiler checked — that the slice was non-empty. The proof existed at compile time. At runtime, it was nothing.

Types as proofs. Once you see it, you can’t unsee it.

Lesson 8: Sealed Traits — Closing extension points

Tue, 16 Sep 2025 09:38:00 +0000

I was designing a public API for a parser library when I realized I had a problem. I wanted users to use my trait — call its methods, pass it as a bound — but I did not want them implementing it for their own types. Every new implementation would need to maintain invariants that I couldn’t enforce through the trait interface alone. If someone implemented it wrong, they’d get subtly broken behavior with no good error message.

Lesson 7: Type-Level Programming — Computing with types

Sat, 13 Sep 2025 11:15:00 +0000

There’s a moment in every Rust programmer’s journey where they look at typenum or some const-generics trick and think: “Wait, we’re doing math at compile time? With the type checker?” Yes. Yes we are. And it’s not a curiosity — it’s the foundation for things like fixed-size matrices, compile-time dimension checking, and provably correct buffer sizes.

I first encountered type-level integers when I needed a matrix library that could guarantee at compile time that you couldn’t multiply a 3x4 matrix by a 2x5 matrix. The dimensions had to match, and I wanted the compiler — not a runtime assertion — to enforce it.

Lesson 6: Variance — Covariance, contravariance, invariance

Thu, 11 Sep 2025 16:42:00 +0000

Variance is the topic that made me realize I didn’t actually understand Rust’s type system as well as I thought I did. I’d been writing Rust for over a year, had shipped production code, even written some unsafe blocks — and then I hit a lifetime error that I could not explain. The borrow checker was rejecting code that looked perfectly fine. Turns out, variance was the reason.

If you’ve ever had a lifetime error that made no sense, variance might be the missing piece.

Lesson 5: Existential Types — impl Trait in depth

Tue, 09 Sep 2025 07:28:00 +0000

I used impl Trait for months thinking it was just syntactic sugar for generics. “It’s the same as a type parameter, right? Just shorter?” No. It’s fundamentally different, and understanding how it’s different unlocks patterns that are genuinely impossible with plain generics.

Let me show you.

Two Positions, Two Meanings

impl Trait means completely different things depending on where you use it:

// Argument position: "I accept any type that implements Iterator"
fn count_items(iter: impl Iterator<Item = i32>) -> usize {
 iter.count()
}

// Return position: "I return some specific type that implements Iterator,
// but I'm not telling you which one"
fn make_numbers() -> impl Iterator<Item = i32> {
 (0..10).filter(|x| x % 2 == 0)
}

In argument position, the caller chooses the concrete type. In return position, the function chooses — and the caller can’t see what it picked. These are fundamentally different concepts from type theory.

Lesson 4: Simulating Higher-Kinded Types in Rust — The workarounds

Sun, 07 Sep 2025 19:03:00 +0000

Every time someone on Reddit says “Rust can’t do higher-kinded types,” a part of me wants to respond with a 200-line code block that proves them… well, partially wrong. Rust doesn’t have native HKTs, that’s true. But the workarounds are surprisingly expressive, and with GATs (generic associated types) now stable, we can get most of what you’d want from HKTs in practice.

Let me walk you through the problem, why it matters, and the patterns that let you work around it.

Lesson 3: Session Types — Protocol safety at compile time

Fri, 05 Sep 2025 10:45:00 +0000

I once spent three days debugging a distributed system where two services were sending messages in the wrong order. Service A expected a handshake acknowledgment before data, but Service B had been refactored to send data first. Both services compiled, both passed their unit tests, and both exploded in production. The protocol contract existed only in a Google Doc that nobody had updated.

Session types fix this. They encode the entire communication protocol in the type system — who sends what, in what order, and when. If you violate the protocol, your code doesn’t compile. Period.

Lesson 2: Advanced Typestate — Multi-state machines at compile time

Wed, 03 Sep 2025 14:17:00 +0000

The first time I implemented a connection pool that couldn’t be misused — not through discipline or documentation, but because the compiler physically rejected invalid state transitions — I felt like I’d discovered a cheat code. Not a runtime check. Not an assertion. A straight-up compiler error if you tried to read from a connection you hadn’t authenticated yet.

This is the typestate pattern taken to its logical extreme. In Lesson 1 we saw the basics with PhantomData and builder states. Now we’re going to encode full multi-state machines where every transition is checked at compile time. No runtime overhead. No state field to match on. Just the type system doing its job.

Lesson 1: Zero-Sized Types — PhantomData, () as design tools

Mon, 01 Sep 2025 08:32:00 +0000

I remember staring at a struct definition in a library I was reading — it had a field of type PhantomData<T> and I thought, “this does literally nothing.” The field takes up zero bytes. It has no runtime representation. Why on earth would you put a field in a struct that doesn’t exist at runtime?

Turns out, zero-sized types are one of the most powerful design tools in Rust. They let you embed meaning into the type system without paying a single byte of overhead. Once you get this, you’ll start seeing ZSTs everywhere — and you’ll start using them yourself.