Atharva Pandey Gopherine

Edit Distance from the previous lesson is the template for a whole family of problems. Any time you’re comparing two strings — finding common parts, matching patterns, counting transformations — you’re drawing a 2D table where one string indexes the rows and the other indexes the columns.

The structure is always the same: dp[i][j] answers a question about the first i characters of one string and the first j characters of the other. The recurrence depends on whether the current characters match and what operations are allowed.

The moment a file system clicked for me was when I stopped thinking of files as “things on disk” and started thinking of them as “names mapped to byte ranges scattered across a block device.” That sounds more complicated, but it’s actually simpler — because now there’s no magic. Just data structures.

Every file system, from FAT16 to ZFS, answers the same fundamental questions: Where does this file’s data live on disk? How do I find a file by name? What metadata (size, permissions, timestamps) does each file have? Let’s answer all of these by building one from scratch.

I used to think I understood processes. Then I tried to implement fork() semantics in Rust and realized I’d been cargo-culting UNIX concepts for years without actually understanding what was happening underneath.

Here’s the thing — Rust forces you to think about OS primitives more carefully than C ever did. The ownership model doesn’t just prevent memory bugs; it makes you confront questions like “who owns a file descriptor?” and “what happens to shared memory after fork?” that C lets you handwave past.

Here’s a scenario that actually happened to me: I had a data validation library written in Rust, a business logic layer in Go, and a reporting module that a client had written in Python. Three languages, three teams, three deployment stories. Traditionally, this means three services talking over HTTP with serialization overhead, network latency, and a distributed systems headache.

With the Component Model, I compiled all three to WASM components, composed them into a single module, and ran the whole pipeline in one process. No network calls, no serialization, no containers. Function calls across language boundaries, at native speed.

In December 2022, Rust officially merged into the Linux kernel source tree. Not as an experiment. Not as a sidecar. As a first-class language for writing kernel code. Linus Torvalds signed off on it.

I remember reading the mailing list thread and thinking: “This is either going to be the most important thing to happen to systems programming in twenty years, or the most spectacular failure.” Three years in, it’s looking a lot like the former.

A pipeline is how you turn a stream of work into a sequence of transformations without writing a single monolithic function that does everything. Each stage reads from one channel, does its thing, and writes to another. Stages compose. Stages are independently testable. And because each stage runs concurrently with every other stage, the whole pipeline processes multiple items simultaneously — like an assembly line rather than a factory worker doing each product start to finish.

About a year ago, I deployed a Rust function as a Cloudflare Worker using WASM. Cold start: 0.5ms. Compare that to a Lambda function in any other language — 50-500ms on a cold start. That’s when I realized WASI isn’t some academic curiosity. It’s the future of server-side compute.

Solomon Hykes — the guy who created Docker — tweeted this back in 2019: “If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker.” He wasn’t being hyperbolic. WASI gives you true sandboxing, near-native performance, cross-platform portability, and sub-millisecond startup. It’s what containers promised, but at a fundamentally lower level.

There’s a moment in every systems programmer’s life when they realize that writing to memory address 0x4002_0818 doesn’t store a value — it turns on an LED. That address isn’t RAM. It’s a hardware register. And the CPU doesn’t know the difference.

That’s memory-mapped I/O in a nutshell, and it’s how virtually all hardware communication works on modern processors. Understanding it properly is the difference between code that happens to work and code that’s correct.

If you’re coming from Python, Java, or JavaScript, Go’s error handling will feel strange at first. There’s no try/catch. No exceptions bubbling up the call stack. Instead, errors are just values — and you deal with them right where they happen. Ignore them and your code doesn’t crash loudly; it quietly lies to you, and you won’t find out until 2am when production is on fire.

The Problem

The blank identifier _ is the most dangerous character in Go. Here’s what it looks like when engineers first start writing Go:

I got a 4.2x speedup on a real-time audio processing pipeline by adding threads to my WASM module. Four threads, 4.2x faster — nearly linear scaling. That almost never happens in practice, but WASM threading hits a sweet spot: the workloads that justify WASM in the first place (heavy computation, large data) are exactly the workloads that parallelize well.

The bad news? Getting threads working in WASM is more involved than std::thread::spawn. There are browser security requirements, Web Worker coordination, shared memory semantics, and a whole build pipeline to figure out. Let me walk you through all of it.