Atharva Pandey Gopherine

Every time I write a proc macro without syn and quote, I regret it within twenty minutes. Raw TokenStream manipulation is like writing HTML by concatenating strings — technically possible, practically unbearable. These two crates are the reason Rust’s proc macro ecosystem works at all. They handle the two hardest parts — parsing Rust syntax into a usable data structure, and generating valid Rust code from a template — so you can focus on the actual logic of your macro.

Before go.work existed, developing across multiple local Go modules was genuinely painful. You were working on a library in one directory and an application that depended on it in another. Every time you changed the library, you had to add a replace directive to the application’s go.mod, run your tests, and then remember — always remember — to remove the replace before committing. I have seen replace directives committed to production go.mod files more times than I would like to admit.

A colleague once asked me why sqlx::query!("SELECT * FROM users WHERE id = $1") can catch SQL errors at compile time. “Is it reading the database during compilation?” Yes. It literally connects to your database, validates the query, checks the types, and generates type-safe Rust code — all before your program runs. That’s a function-like proc macro doing things that feel illegal. And the mechanics behind it are more straightforward than you’d think.

I was reviewing a codebase that used Actix Web and kept seeing #[get("/users")] on handler functions. I knew it was a macro, but I didn’t understand the mechanics — how does an attribute on a function transform the function? Where does the routing registration happen? When I finally built my own attribute macro, the whole system clicked. Attribute macros aren’t magic. They’re just functions that receive code and return different code.

Level by level. That phrase shows up in maybe a third of binary tree interview problems, sometimes explicitly and sometimes disguised. “What would you see from the right side?” Level by level. “What is the minimum number of steps from root to a leaf?” Level by level. “Connect each node to its right neighbor on the same level?” Level by level.

BFS on trees feels simpler than BFS on graphs because trees have no cycles and no visited-set bookkeeping. But the interesting problems are not about the traversal itself — they are about what you do with the level structure that BFS naturally exposes. In this lesson, I focus on three problems that are each a variation on one theme: level order traversal plus one clever twist per problem.

Every performance optimization ultimately makes the same trade: you’re giving up memory to gain CPU time, or giving up CPU time to reduce memory usage. There’s no free lunch. The skill isn’t knowing that the tradeoff exists — it’s knowing which side of it you’re on, and making the choice consciously rather than accidentally. I’ve optimized for memory when the bottleneck was CPU, and optimized for CPU when memory was the problem. Both directions are wrong when you pick them without data.

The first derive macro I shipped to production generated about 200 lines of boilerplate per struct. We had 47 structs. That’s 9,400 lines of code I didn’t have to write, test, or maintain. Every time someone added a field to a struct, the derive macro picked it up automatically. No manual updates, no forgotten implementations, no “oh I changed the struct but forgot to update the builder” bugs. Derive macros are the highest-leverage tool in Rust’s macro system, and once you build one, you’ll find excuses to build more.

I have reviewed Go code from developers who learned other languages where exceptions are the primary error handling mechanism. In Ruby, Python, or Java, you throw an exception and it propagates up the stack until something catches it. In Go, the analogous mechanism — panic — has a very different contract. A panic that is not recovered crashes the entire process. In a web server, that means every in-flight request dies. In a worker process, that means all queued work is dropped.

The moment I realized macro_rules! couldn’t generate new identifier names from captured inputs, I knew I needed something more powerful. I was trying to auto-generate a _builder suffix for struct names — take Config and produce ConfigBuilder. Declarative macros can’t do string manipulation on identifiers. Period. That’s what pushed me into procedural macros, and honestly, it felt like unlocking a completely different layer of the language.

What Procedural Macros Actually Are

A procedural macro is a Rust function that runs at compile time. It receives a stream of tokens as input, does whatever processing it wants — parsing, analyzing, transforming — and returns a new stream of tokens as output. The compiler then compiles the returned tokens as if they were regular source code.

A flaky test is a test that sometimes passes and sometimes fails with no code change in between. It sounds like a minor annoyance. It’s actually corrosive. Once your team learns that the test suite sometimes fails for “no reason,” they start merging on red. They start dismissing failures. They lose trust in the test suite as a signal. A single reliably-failing test is informative; a dozen flaky tests teach your team to ignore failures. I’ve seen this destroy test suite culture on multiple teams.