Atharva Pandey Gopherine

Before I understood event loops, I thought async I/O was some kind of kernel magic. You register interest in a socket, and somehow the OS tells you when data arrives — without blocking a thread. How? I imagined complex kernel subsystems doing heavy lifting behind the scenes.

Turns out, the mechanism is almost embarrassingly simple. The kernel maintains a list of file descriptors you care about. When something happens on one of them, it flips a bit. You ask “what happened?”, it tells you. That’s it. The entire async I/O ecosystem — Tokio, Node.js, nginx, everything — is built on this one primitive.

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.

I ran a benchmark last year that genuinely surprised me. A simple TCP echo server using io_uring was handling 40% more connections per second than the same server on epoll, with measurably lower tail latencies. Not 5% — forty percent. On the same hardware, same kernel version, same application logic. That’s when I stopped treating io_uring as a curiosity and started treating it as the future of Linux I/O.

If you’ve been building async runtimes on epoll (or even kqueue on macOS), io_uring changes the game completely. Let me show you why.

Interval DP is the pattern that solves problems where you need to find the optimal way to process a contiguous segment, and the answer depends on how you choose to “split” or “last-process” within that segment. The classic examples — Burst Balloons, Matrix Chain Multiplication, Optimal BST — all share the same skeleton: try every possible “last operation” position k within [i, j], and combine the subproblems for [i, k] and [k, j].

There’s a class of production bugs I see over and over — and the cause is almost always the same: nothing is telling the program to slow down. A spike in traffic arrives, every goroutine blasts outbound, and suddenly you’ve got five hundred simultaneous connections against a Postgres instance that’s configured for a hundred. The database starts rejecting connections. The application throws errors. Everyone’s paged at 2am.

The fix isn’t complicated. It’s a semaphore — a primitive that limits how many concurrent operations are in flight at once. Go doesn’t ship a dedicated semaphore type, but it doesn’t need to. A buffered channel of the right size is a semaphore, and that insight unlocks a whole class of resource-limiting patterns.

The moment I built my first executor from scratch, async Rust stopped being scary. Not because executors are simple — they’re not — but because once you see the machinery, every “mysterious” behavior has an obvious explanation. Futures hanging? The waker isn’t being called. Tasks not making progress? The executor’s run loop has a bug. Performance terrible? You’re probably polling too aggressively or not enough.

So let’s build one. A real, working executor. Not a production-quality one (that’s Tokio’s job), but one that actually runs futures to completion, handles multiple tasks, and demonstrates every concept from the previous lesson.

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.

I thought I understood Rust futures until I tried to implement one without async/await. Not a toy future that immediately returns Ready. A real future — one that yields, gets woken up, and resumes where it left off. That exercise broke every mental model I had and rebuilt it from scratch.

The async/await syntax is one of Rust’s great lies. It looks simple. It feels like you’re writing sequential code. Under the hood, the compiler is generating state machines, threading waker references through call graphs, and constructing self-referential structs that would make most C++ programmers nervous. Let’s rip the lid off.

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.

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.