Lesson 10: Zero Values Are Useful — Go types that work before you touch them</h1> <article> <h1>Lesson 10: Zero Values Are Useful — Go types that work before you touch them</h1> <p>Mon, 09 Mar 2026 00:00:00 +0000</p> <p>In most languages, a freshly declared variable is either uninitialized garbage you can’t touch safely, or it needs a constructor call before it does anything useful. Go takes a different approach: every variable always has a value. When you don’t provide one, Go assigns the zero value for the type. What makes this interesting is that Go’s standard library is full of types designed so that their zero value is immediately useful — no constructor required.</p> </article> <article> <h1>Lesson 40: Mock Interview Strategy — The 45-minute framework for any problem</h1> <p>Sun, 01 Mar 2026 00:00:00 +0000</p> <p>I have had interviews where I solved the problem correctly and still got rejected. I have also had interviews where I struggled significantly with the solution but received strong positive feedback. The difference was not the code — it was everything around the code. How I communicated, how I managed time, how I responded when I got stuck, and whether the interviewer felt like they had seen how I actually think.</p> </article> <article> <h1>Lesson 12: Value vs Pointer Receivers — The method that silently does nothing</h1> <p>Mon, 23 Feb 2026 00:00:00 +0000</p> <p>Value vs pointer receivers is one of those topics that seems like a style preference until it silently breaks your program. The tell is a method that looks like it mutates a struct, compiles without complaint, but the mutations simply don’t persist. You add a log line, the value is right inside the method — and wrong the moment the method returns.</p> <h2 id="the-problem">The Problem</h2> <p>A value receiver operates on a copy. Every time you call the method, Go copies the entire struct and passes the copy to the method. Mutations happen on the copy, which gets discarded when the method returns. The original is untouched.</p> </article> <article> <h1>Lesson 28: Production Concurrency Architecture — Putting it all together</h1> <p>Fri, 20 Feb 2026 00:00:00 +0000</p> <p>This is the lesson I wish existed when I started. Not “here’s how channels work” or “here’s a simple worker pool” — but the full picture: how you take everything you’ve learned about goroutines, channels, contexts, rate limiting, idempotency, observability, and graceful shutdown and assemble it into a service that actually belongs in production. One that handles failures, recovers gracefully, doesn’t leak resources, and gives you the visibility to understand what it’s doing.</p> </article> <article> <h1>Lesson 9: Testing with Real Databases — Mocking sql.DB is lying to yourself</h1> <p>Wed, 18 Feb 2026 00:00:00 +0000</p> <p>For years, the standard advice for testing Go database code was to use <code>sqlmock</code> — a library that intercepts database calls and lets you assert which queries were run. I used it for a while. Then I started finding production bugs that my <code>sqlmock</code> tests were actively hiding: constraint violations that only happen with real Postgres, query plan differences, JSON operator behavior, NULL handling edge cases, transaction isolation behavior. <code>sqlmock</code> tests were passing while the same code was failing in production. That’s worse than no tests at all.</p> </article> <article> <h1>Lesson 39: Hard Composites — When one pattern isn't enough</h1> <p>Sun, 15 Feb 2026 00:00:00 +0000</p> <p>There is a class of interview problem designed specifically to differentiate senior candidates. These are not problems where knowing one pattern is enough — they require you to recognize that two or three patterns need to compose, figure out the seam between them, and implement the composition cleanly under pressure. I call them hard composites.</p> <p>The candidates who struggle here usually know the individual patterns. The gap is the synthesis. They apply binary search but miss that the search space itself requires a merge step. They build the trie but miss that the relationships between words encode a graph that needs topological sort. Practice the composites explicitly, not just their constituent patterns.</p> </article> <article> <h1>Lesson 19: Table-Driven Tests — One test function, fifty test cases</h1> <p>Mon, 09 Feb 2026 00:00:00 +0000</p> <p>Most engineers know to write tests. Fewer think about how the test code itself should scale. When you need to cover thirty input variations of a function, duplicating the test body thirty times produces something that’s painful to read, painful to extend, and painful to debug when it fails. Table-driven tests are the pattern that scales. A slice of cases, one loop — your test code stays as clean as your production code.</p> </article> <article> <h1>Lesson 27: Idempotency in Concurrent Systems — Assume everything runs twice</h1> <p>Sun, 08 Feb 2026 00:00:00 +0000</p> <p>Every distributed system I’ve worked on eventually ran something twice. A retry after a timeout. A duplicate webhook delivery. A job that got processed by two workers simultaneously because of a clock skew issue in the claim timeout logic. A user who double-clicked a submit button. Systems aren’t gentle about this — they don’t ask “are you sure?” before running your code again. They just run it. The question isn’t whether your code will ever run twice. It’s whether running it twice causes a problem.</p> </article> <article> <h1>Lesson 38: Design Problems — Build it from scratch in 30 minutes</h1> <p>Tue, 03 Feb 2026 00:00:00 +0000</p> <p>Design problems in coding interviews are different from system design rounds. You are not sketching architecture at a whiteboard — you are implementing a concrete data structure from scratch, live, in 30 to 45 minutes. The interviewer cares about both correctness and your choices of underlying data structures. “Just use a map” is never a complete answer.</p> <p>I find these problems particularly satisfying because the solutions are compact. Once you see the underlying pattern — that almost every caching and feed problem requires a hash map layered on top of an ordered structure — the implementations become variations on a theme.</p> </article> <article> <h1>Lesson 8: Migrations Without Downtime — ALTER TABLE can lock your entire database</h1> <p>Tue, 27 Jan 2026 00:00:00 +0000</p> <p>The first time I caused a production outage with a database migration, I was adding a <code>NOT NULL</code> column to a table. The migration looked innocent. It ran fine on staging with 1,000 rows. In production with 40 million rows, it locked the entire table for 11 minutes while Postgres rewrote every row. Every write to that table failed with a lock timeout. We rolled back the app but couldn’t roll back the migration. It was a terrible morning.</p> </article> <article> <h1>Lesson 22: Small Packages Win — One package, one job</h1> <p>Mon, 26 Jan 2026 00:00:00 +0000</p> <p>There is a particular kind of Go codebase that’s immediately recognizable as written by someone still thinking in another language. It has a <code>utils</code> package. Maybe a <code>common</code> package. Possibly a <code>helpers</code> folder with a file called <code>misc.go</code>. Every function that doesn’t obviously belong somewhere ends up there, and over time these packages become the junk drawers of the codebase — bloated, unfocused, and imported by everything.</p> <p>Go has a better way. Small packages with narrow responsibilities. One package, one idea.</p> </article> <article> <h1>Lesson 26: Safe Background Jobs in Web Servers — Don''t spawn goroutines in handlers</h1> <p>Fri, 23 Jan 2026 00:00:00 +0000</p> <p>The first time I saw <code>go func()</code> inside an HTTP handler, I thought it was clever. Fire off the slow work in the background, respond to the client fast, everybody wins. Then I watched what happened when we deployed a new version: the server started shutting down, half the background goroutines got killed mid-operation, we had partial writes in the database and no way to know which ones had completed. The “clever” optimization had created a correctness nightmare. The real problem wasn’t the goroutine — it was that it was invisible to the server’s shutdown lifecycle.</p> </article> <article> <h1>Lesson 37: Concurrency Problems — The questions Google loves</h1> <p>Sun, 18 Jan 2026 00:00:00 +0000</p> <p>Concurrency problems are the ones where an interviewer can tell immediately whether you actually understand concurrency or have just memorized solutions. They are also the problems where Go shines brightest — goroutines and channels are so expressive for synchronization that solutions which require dense mutex orchestration in Java become almost self-documenting in Go.</p> <p>Google, in particular, loves these. I have heard this pattern described by multiple engineers who have been through their interview loops: “expect at least one problem where you need to coordinate goroutines.” The underlying skill being tested is not just “can you prevent a race condition” — it is “do you understand which primitives to reach for, and can you reason about your solution’s correctness?”</p> </article> <article> <h1>Lesson 25: Observability for Concurrency — You can''t fix what you can''t see</h1> <p>Thu, 15 Jan 2026 00:00:00 +0000</p> <p>The goroutine leak doesn’t announce itself. It just slowly inflates your memory graph — 50MB, 80MB, 150MB — until either your alerting fires or the OOM killer shows up. Then you’re staring at a core dump or (if you’re lucky) a live process trying to figure out which of the 10,000 goroutines running in your service is the culprit. I’ve been there. It’s not fun. The difference between spending 20 minutes diagnosing a leak and spending 4 hours diagnosing a leak is almost entirely whether you invested in observability before the incident.</p> </article> <article> <h1>Lesson 7: Slices Are Views, Not Arrays — Mutations you didn''t ask for</h1> <p>Mon, 12 Jan 2026 00:00:00 +0000</p> <p>If you’re coming from Python, JavaScript, or Java, slices look familiar enough that you’ll assume you understand them. That assumption will hold right up until something mutates data you didn’t expect to be mutable, or a change you made inside a function mysteriously doesn’t show up outside it. Both surprises have the same root cause: a slice is not a copy of its data, it’s a window into an underlying array that may be shared with other slices.</p> </article> <article> <h1>Lesson 36: Intervals — Sort by start, merge by end</h1> <p>Mon, 05 Jan 2026 00:00:00 +0000</p> <p>Interval problems show up everywhere — in calendar APIs, in resource scheduling, in genomics, in timeline visualizations. In interviews they appear in a small number of canonical forms, and every form reduces to the same underlying operation: sort by start time, then sweep left to right making decisions based on where the current interval’s end overlaps with the next interval’s start.</p> <p>I have seen engineers panic at interval problems because the cases feel fiddly. Overlapping but not containing. Contained entirely. Adjacent but not touching. Once you drill the sort-and-sweep template into muscle memory, you handle all the cases in a single pass without tracking them explicitly.</p> </article> <article> <h1>Lesson 24: Testing Concurrent Code — Flaky tests mean flaky design</h1> <p>Tue, 30 Dec 2025 00:00:00 +0000</p> <p>A flaky test is a lie your codebase tells you. It says “this sometimes works and sometimes doesn’t” and if you’re honest with yourself, you already know what that means: there’s a race condition somewhere, and the test is just unlucky enough to expose it occasionally. I used to mark flaky tests with <code>t.Skip("flaky, fix later")</code> and move on. I stopped doing that when a race condition that a flaky test was hinting at caused a double-charge bug in production. Now I treat every flaky test as a production incident waiting to happen.</p> </article> <article> <h1>Lesson 25: Simplicity Is a Language Feature — Why Go says no so you can ship</h1> <p>Mon, 29 Dec 2025 00:00:00 +0000</p> <p>Every Go design decision that looks like a missing feature is actually a deliberate choice to remove cognitive overhead. No method overloading. No implicit conversions. One canonical formatter. Generics that arrived late and deliberately. Go’s simplicity is not an accident — it’s a feature, and one that pays compounding dividends as a codebase and team grow.</p> <h2 id="the-problem">The Problem</h2> <p>Languages that offer maximum expressiveness also offer maximum inconsistency. In Java or C++, method overloading sounds convenient:</p> </article> <article> <h1>Lesson 7: The N+1 Problem — One query per row is a performance bug</h1> <p>Thu, 25 Dec 2025 00:00:00 +0000</p> <p>The N+1 problem is the most common database performance issue I find when reviewing Go code, and it’s especially sneaky because it looks totally fine in development. You have a list of 10 users, you fetch their orders, 11 queries, no problem. You deploy to production, the table has 50,000 users, your endpoint suddenly takes 40 seconds, and you get a 3am page. The queries were always there — you just didn’t notice them until the data grew.</p> </article> <article> <h1>Lesson 35: Greedy — Local optimal leads to global optimal (sometimes)</h1> <p>Tue, 23 Dec 2025 00:00:00 +0000</p> <p>Greedy algorithms have a brutal failure mode in interviews: the solution looks obvious, you implement it in fifteen minutes, and then the interviewer asks “does this always work?” and you have no good answer. I have been on both sides of that question. Greedy is powerful when the problem has the right structure, and dangerously wrong when it does not.</p> <p>The discipline is learning to tell the difference. Most greedy interview problems are structured so that a correct greedy choice exists — the challenge is identifying what that choice is and, if asked, arguing why locally optimal decisions accumulate to a globally optimal result.</p> </article> <article> <h1>Lesson 23: Distributed vs Local Concurrency — Channels don''t cross process boundaries</h1> <p>Mon, 22 Dec 2025 00:00:00 +0000</p> <p>There’s a particular kind of confidence that comes after you’ve spent a few months writing Go. You’ve learned channels, you understand the happens-before guarantees, you’ve built a worker pool that hums along beautifully. Then someone says “we need to scale this across multiple pods” and you think: easy, I’ll just make the channels bigger. That thought has caused more production incidents than I care to remember — including one where we lost about 3,000 job records because a pod restarted mid-processing and nobody had thought about what “at-least-once delivery” actually means.</p> </article> <article> <h1>Lesson 17: select Is Elegant — Waiting on multiple futures without blocking</h1> <p>Mon, 15 Dec 2025 00:00:00 +0000</p> <p>Every non-trivial concurrent program eventually needs to wait on more than one thing at a time. Maybe you’re waiting on a job channel but also need to respond to cancellation. Maybe you want to fetch from a channel but bail out after a timeout. Sequential channel receives can’t do this — they block on one thing and miss everything else. <code>select</code> is the solution, and it’s more powerful than it looks.</p> </article> <article> <h1>Lesson 34: Backtracking — Try everything, undo what doesn't work</h1> <p>Thu, 11 Dec 2025 00:00:00 +0000</p> <p>Backtracking scared me for a long time. The problems looked like they needed some clever mathematical insight — some observation that would magically reduce the search space. Then I realized the actual technique is almost mechanical: build a candidate solution incrementally, check constraints at each step, and undo your last choice if the current path cannot lead anywhere valid. That’s it. The art is in recognizing when to prune.</p> <p>Every backtracking solution I have ever written follows the same skeleton. Once that skeleton is internalized, the remaining work is problem-specific constraint checking. The code almost writes itself.</p> </article> <article> <h1>Lesson 22: Rate Limiting and Load Shedding — Say no before you fall over</h1> <p>Wed, 10 Dec 2025 00:00:00 +0000</p> <p>The most honest thing a server can do is say “no.” Not crash, not time out after 30 seconds, not queue work indefinitely until memory explodes — just return a clean 503 and let the caller decide what to do. I spent a long time thinking rate limiting was about protecting <em>users</em> from themselves. Then I got paged at midnight because a misbehaving client hammered an endpoint, the service queued everything politely, RAM climbed to the ceiling, and the process died. The fix wasn’t more memory. It was teaching the service to refuse work it couldn’t handle.</p> </article> <article> <h1>Lesson 6: Context with Database Queries — Every query needs a timeout</h1> <p>Wed, 03 Dec 2025 00:00:00 +0000</p> <p>We once had a query that ran for 47 minutes. I’m not joking. A reporting query that worked fine on the test dataset decided to do a full sequential scan on a 200M-row table in production because someone dropped an index by accident the night before. The query just ran. And ran. And ran. The connection was held the whole time, blocking the pool. New requests started queuing. Within 10 minutes, the service was effectively down — not because of an error, but because every database connection was held by queries waiting for that one slow one to finish.</p> </article> <article> <h1>Lesson 9: range Gotchas — The loop variable that bit every Go team</h1> <p>Mon, 01 Dec 2025 00:00:00 +0000</p> <p><code>range</code> looks harmless. Index and value, loop over a slice — what could go wrong? Quite a bit, it turns out. Some of the most insidious bugs I’ve seen in Go codebases come from assumptions about <code>range</code> that seem obvious but are wrong. One was painful enough that Go 1.22 changed the fundamental loop semantics to fix it. Let’s walk through each gotcha and the correct pattern to use.</p> <h2 id="the-problem">The Problem</h2> <p>The classic range bug — the one that famously broke production code at teams large and small for years — is the loop variable capture problem. In Go versions before 1.22, every iteration of a <code>range</code> loop reused the same loop variable. Taking its address multiple times gave you the same address every time.</p> </article> <article> <h1>Lesson 33: Trie — When you need prefix matching</h1> <p>Wed, 26 Nov 2025 00:00:00 +0000</p> <p>Tries showed up in a Google interview I did early in my career. The problem was autocomplete. I started sketching a hash map of prefixes to word lists and immediately knew something was wrong — the interviewer was watching too patiently. The correct structure, the one that makes the solution feel inevitable, is a trie. It organizes words so that every prefix lookup is just a traversal of shared nodes, and I had been fighting to reconstruct that structure from scratch.</p> </article> <article> <h1>Lesson 21: Supervisor Patterns — Let it crash, then restart it</h1> <p>Tue, 25 Nov 2025 00:00:00 +0000</p> <p>Erlang got famous for the “let it crash” philosophy. The idea is that trying to handle every possible error in every possible place produces fragile, complicated code. It’s often better to let a process crash cleanly and have a supervisor restart it. The supervisor knows how to bring the process back to a known-good state. The process itself just needs to do its job and fail fast when something’s wrong.</p> </article> <article> <h1>Lesson 24: Prefer Plain Structs — Boring code is correct code</h1> <p>Mon, 17 Nov 2025 00:00:00 +0000</p> <p>There is a particular brand of cleverness that feels deeply satisfying to write and deeply painful to maintain. The <code>AbstractServiceProviderFactory</code>. The builder that returns a builder that configures a builder. The generic interface so abstract it could model anything and therefore models nothing well. Go’s culture pushes back hard against this tendency, and for good reason: I’ve seen more bugs traced to abstraction layers than to simple structs.</p> <h2 id="the-problem">The Problem</h2> <p>The most common form of over-engineering in Go is attempting to import Java-style construction patterns. Go doesn’t have constructors, so engineers invent them — and the result is code that’s harder to configure, not easier:</p> </article> <article> <h1>Lesson 20: Profiling Contention — pprof knows where your goroutines sleep</h1> <p>Thu, 13 Nov 2025 00:00:00 +0000</p> <p>You’ve added goroutines, you’ve got worker pools, you’ve written careful concurrent code — and the service is still slower than expected. Maybe goroutine count is climbing in your metrics dashboard. Maybe p99 latency has a long tail you can’t explain. Maybe a throughput test plateaus at 40% of what you thought the hardware should support.</p> <p>This is where guessing stops and profiling starts. Go ships world-class concurrency profiling tools in the standard library — mutex profiles, block profiles, goroutine dumps, and the execution tracer. Most engineers know about the CPU and memory profiler. Far fewer use the concurrency-specific profiles, which is a shame because they find the exact thing that’s wrong in minutes instead of days.</p> </article> <article> <h1>Lesson 32: Heap Patterns — Keep the top K without sorting everything</h1> <p>Tue, 11 Nov 2025 00:00:00 +0000</p> <p>The first time I saw a “find the K largest elements” problem in an interview, I sorted the array and returned the last K. Correct answer, wrong approach. Sorting costs O(n log n). A heap does it in O(n log K). When n is a billion and K is ten, that difference matters enormously — and the interviewer knows it.</p> <p>Heaps feel mystical until you internalize one thing: a heap is not a sorted array. It is a partially ordered tree that guarantees one thing — you can get the minimum (or maximum) element in O(1) and remove it in O(log n). That partial ordering is enough to solve an entire class of problems that would otherwise require full sorting.</p> </article> <article> <h1>Lesson 10: When Not to Use Rust — Honest trade-offs</h1> <p>Wed, 05 Nov 2025 11:46:00 +0000</p> <p>I like Rust. I’ve written 9 lessons about using it in production. I think it’s one of the most well-designed languages of the last twenty years. And I’m about to spend an entire article telling you when you shouldn’t use it.</p> <p>Because the most dangerous engineers aren’t the ones who don’t know Rust — they’re the ones who think Rust is always the answer. I’ve been that engineer. I once argued for rewriting a Flask API endpoint in Rust because “the response time was too high.” The response time was 200ms, and 180ms of that was a database query. Rust would have saved us maybe 5ms of JSON serialization. My team lead asked me to go take a walk.</p> </article> <article> <h1>Lesson 11: Nil Slice vs Empty Slice — Same length, different meaning</h1> <p>Mon, 03 Nov 2025 00:00:00 +0000</p> <p>Go has two ways to have a slice with zero elements, and they are not the same thing. Developers coming from Python, Ruby, or JavaScript expect an empty collection to just be an empty collection. In Go, the distinction between a nil slice and an empty slice is subtle enough that you can miss it for months — right up until a frontend engineer files a bug because your API is returning <code>null</code> instead of <code>[]</code>.</p> </article> <article> <h1>Lesson 9: War Stories — Lessons from real Rust deployments</h1> <p>Sun, 02 Nov 2025 15:08:00 +0000</p> <p>Every language looks great in blog posts. Production is where the truth comes out. I’ve been running Rust services in production for a few years now, and while I’m convinced it’s the right tool for certain problems, I’ve also hit situations where Rust did something I didn’t expect, or where its strengths became weaknesses in surprising ways.</p> <p>These are real stories. Some names and details are changed, but the bugs and the lessons are exactly as they happened.</p> </article> <article> <h1>Lesson 19: Ordering vs Throughput — You can have fast or ordered, pick one</h1> <p>Fri, 31 Oct 2025 00:00:00 +0000</p> <p>Here’s a tension that comes up in almost every real concurrent system: you want to process things fast, which means doing them in parallel, but the output needs to come out in the same order the input arrived. These two goals are in direct conflict. Parallel execution means things finish in unpredictable order. Ordered output means you have to wait for the slowest thing in each batch.</p> <p>The engineers who understand this tension build systems that make the trade-off explicitly. The engineers who don’t notice it build systems that either throttle themselves to single-goroutine throughput “to preserve order” or silently return results in the wrong order and wonder why tests fail non-deterministically.</p> </article> <article> <h1>Lesson 8: Migrating Services from Go/Python/Java to Rust — When and how</h1> <p>Thu, 30 Oct 2025 09:33:00 +0000</p> <p>I’ve been involved in three Rust migrations. One from Python, one from Go, one from Java. Two were successes. One was a disaster that got cancelled six months in after burning a quarter of the team’s roadmap capacity.</p> <p>The failed one wasn’t a technical failure — the Rust code was fine. It failed because we rewrote the wrong service, at the wrong time, for the wrong reasons. “Rust is faster” was the entire justification. Nobody had measured whether speed was actually the bottleneck.</p> </article> <article> <h1>Lesson 31: Monotonic Stack — The next greater element trick</h1> <p>Thu, 30 Oct 2025 00:00:00 +0000</p> <p>I used to brute-force “next greater element” problems. Nested loops, O(n²), and a silent prayer that the input was small. Then a senior engineer at a Google mock interview drew me a picture of a stack where elements got popped the moment something bigger walked in, and the pattern clicked instantly. The monotonic stack is one of those techniques that, once you see it, you wonder how you ever missed it.</p> </article> <article> <h1>Lesson 5: sqlc vs ORM vs Raw SQL — Pick your tradeoff, not your religion</h1> <p>Wed, 29 Oct 2025 00:00:00 +0000</p> <p>Every time someone asks “should I use GORM or raw SQL?” a flame war breaks out. I’ve been on both sides of that argument, and I’ve shipped production systems using all four approaches — raw SQL, GORM, sqlc, and Ent. My opinion now is boring: each one is the right choice in a specific context, and none of them is universally correct. The question isn’t which one is best, it’s which tradeoffs you’re signing up for.</p> </article> <article> <h1>Lesson 7: Feature Flags at the Type Level — Compile-time feature control</h1> <p>Tue, 28 Oct 2025 13:19:00 +0000</p> <p>We had a feature that was ready for staging but absolutely not ready for production. In my previous Go gig, we’d have used a runtime feature flag service — LaunchDarkly or similar. Evaluate a boolean at request time, show the new code path to internal testers, hide it from everyone else.</p> <p>In Rust, we had another option. We could decide <em>at compile time</em> whether the feature existed in the binary at all. Not a runtime check. Not a boolean. The code literally wasn’t in the production binary. You couldn’t accidentally enable it. You couldn’t exploit it. It didn’t exist.</p> </article> <article> <h1>Lesson 6: API Versioning and Backwards Compatibility — Don't break your users</h1> <p>Sun, 26 Oct 2025 10:55:00 +0000</p> <p>I once shipped a “minor” API change on a Friday. Renamed a JSON field from <code>user_name</code> to <code>username</code>. Seemed harmless — we were cleaning up inconsistencies. By Monday morning, we had 14 support tickets from integration partners whose parsers broke. One partner had hardcoded the field name into a system that processed payroll. People didn’t get paid because I renamed a JSON field.</p> <p>That was the last time I treated backwards compatibility as optional.</p> </article> <article> <h1>Lesson 5: Multi-Crate Workspace Architecture — Scaling your codebase</h1> <p>Thu, 23 Oct 2025 16:42:00 +0000</p> <p>Our compile times hit 8 minutes. Not from scratch — <em>incremental</em>. Change one line in the domain model and wait 8 minutes to see if it worked. Three engineers were actively avoiding making changes to shared code because the feedback loop was unbearable.</p> <p>The problem was obvious: everything lived in one crate. The domain model, the HTTP handlers, the database layer, the gRPC server, the background workers — all sharing one <code>Cargo.toml</code> with 47 dependencies. Touch anything and the whole thing recompiles.</p> </article> <article> <h1>Lesson 10: Interpreter Pattern — DSLs and parsing</h1> <p>Wed, 22 Oct 2025 12:00:00 +0000</p> <p>A few years ago I needed to let non-technical users define filtering rules for a data pipeline. The options were: embed Lua, use a YAML config with increasingly awkward syntax, or write a small domain-specific language. I picked the DSL. It took two days in Rust, and the result was a type-safe, sandboxed expression evaluator that couldn’t crash the host program no matter what users typed. Try getting that guarantee with dynamic code execution in Python.</p> </article> <article> <h1>Lesson 4: CQRS and Event Sourcing — Separating reads from writes</h1> <p>Tue, 21 Oct 2025 08:27:00 +0000</p> <p>We had this inventory service that was doing fine until it wasn’t. Reads were simple — “how many units of product X are available?” Writes were complex — reservations, adjustments, transfers between warehouses, reconciliation with physical counts. Both read and write operations hit the same database table, the same data model, and the same set of queries that were getting increasingly gnarly.</p> <p>Then we hit Black Friday. Read traffic spiked 40x. The complex write queries were locking rows that the read queries needed. We couldn’t scale reads without scaling writes. We couldn’t optimize the read path without breaking the write path’s invariants.</p> </article> <article> <h1>Lesson 18: sync.Mutex Is Often Simpler — Not everything needs a channel</h1> <p>Mon, 20 Oct 2025 00:00:00 +0000</p> <p>After you absorb the Go concurrency philosophy — share memory by communicating — there’s a temptation to reach for channels every time two goroutines need to share data. Resist that. Channels are for coordination and ownership transfer. For shared mutable state that multiple goroutines read and write, a mutex is usually clearer, simpler, and faster. Using a channel where a mutex belongs is one of those things that looks idiomatic but isn’t.</p> </article> <article> <h1>Lesson 9: Entity Component System — Data-oriented design</h1> <p>Sun, 19 Oct 2025 15:30:00 +0000</p> <p>I spent years thinking about game objects the OOP way. A <code>Player</code> extends <code>Character</code> extends <code>Entity</code>. A <code>Goblin</code> extends <code>Enemy</code> extends <code>Character</code> extends <code>Entity</code>. Then someone asks “what if a goblin can be mind-controlled and act like a player?” and your inheritance hierarchy collapses.</p> <p>ECS — Entity Component System — is the answer that the game development world converged on, and it’s fundamentally a Rust-shaped idea. Data and behavior are separated. Composition replaces inheritance. Cache-friendly memory layouts replace pointer-chasing object graphs. Rust’s ownership model maps onto ECS so naturally that Bevy — the most popular Rust game engine — is built entirely around it.</p> </article> <article> <h1>Lesson 3: Hexagonal Architecture in Rust — Ports, adapters, and boundaries</h1> <p>Sun, 19 Oct 2025 11:05:00 +0000</p> <p>About a year ago, I had to swap out our payment provider. In Go, that would’ve been a two-week project — chasing down every place we called Stripe’s SDK, updating structs, fixing test mocks. In our Rust service, it took a day and a half. The reason wasn’t Rust itself. It was how we’d structured the code.</p> <p>Hexagonal architecture (sometimes called “ports and adapters”) is one of those patterns that sounds academic until you actually need to replace a database, swap a message broker, or test your business logic without spinning up Docker containers. In Rust, traits make it feel natural rather than ceremonial.</p> </article> <article> <h1>Lesson 18: Backpressure Design — Slow down or blow up</h1> <p>Sun, 19 Oct 2025 00:00:00 +0000</p> <p>Every system has a throughput ceiling. The question isn’t whether your service can be overwhelmed — it can. The question is what happens when it is. Does it slow down gracefully, maintaining correctness and giving the caller a clear signal? Or does it blow up — OOM-killed, goroutines piling up, latency spiking to infinity while requests pile up in an unbounded queue?</p> <p>Backpressure is the mechanism that answers that question. It’s how a component communicates to its upstream: “I’m full — slow down.” Without it, fast producers eat slow consumers alive. In Go, backpressure is naturally expressed through blocking channel sends — and understanding when to block versus when to drop is one of the more interesting design decisions in concurrent systems.</p> </article> <article> <h1>Lesson 2: Domain Modeling with Rust's Type System — Making impossible states impossible</h1> <p>Fri, 17 Oct 2025 14:38:00 +0000</p> <p>We shipped a bug to production that cost us about three hours of incident response and a very uncomfortable Slack thread. The root cause? Someone passed a <code>user_id</code> where an <code>order_id</code> was expected. Both were <code>String</code>. Both were UUIDs. The compiler had no way to tell them apart. The function signature said <code>fn cancel_order(order_id: String, user_id: String)</code>, and someone called it with the arguments flipped.</p> <p>This is the kind of bug that makes you rethink everything. Not because it’s complex — because it’s <em>stupid</em>. And stupid bugs that slip through a strong type system mean the type system wasn’t being used right.</p> </article> <article> <h1>Lesson 30: Bitmask DP — When the state is a set</h1> <p>Fri, 17 Oct 2025 00:00:00 +0000</p> <p>Every DP pattern we’ve covered has kept the state manageable: an index, a remaining budget, a mode. Bitmask DP enters the picture when the state is a <em>subset</em> of elements — specifically, which elements from a small set have been included or visited so far.</p> <p>The representation is elegant: a bitmask of n bits, where bit i is 1 if element i is in the current subset and 0 otherwise. With n = 20, there are 2²⁰ ≈ 1 million possible subsets. That’s the practical ceiling for bitmask DP — you’ll see n ≤ 20 in problem constraints, and that’s the signal.</p> </article> <article> <h1>Lesson 8: Middleware / Chain of Responsibility — Tower-style</h1> <p>Thu, 16 Oct 2025 07:15:00 +0000</p> <p>If you’ve built anything with Express, Koa, or ASP.NET, you know middleware. A request comes in, passes through a chain of handlers — logging, auth, rate limiting, CORS — and eventually reaches your application logic. Each handler can modify the request, short-circuit the chain, or pass it along.</p> <p>The Chain of Responsibility pattern from the GoF book is basically the same thing. The difference is branding.</p> <p>What makes this pattern interesting in Rust is <code>tower</code> — the crate that defines how middleware works across the entire Rust async ecosystem. Axum, Tonic, Hyper — they all use Tower’s <code>Service</code> trait. Understanding it unlocks the middleware patterns in all of these frameworks.</p> </article> <article> <h1>Lesson 1: Structuring a Large Rust Application — Beyond hello world</h1> <p>Wed, 15 Oct 2025 09:14:00 +0000</p> <p>The moment I knew our Rust project structure was broken was when a junior engineer asked me where to put a new endpoint. I opened the repo, stared at the <code>src/</code> directory, and realized I couldn’t confidently answer. We had 40,000 lines of Rust spread across files with names like <code>utils.rs</code>, <code>helpers.rs</code>, <code>types.rs</code>, and the ever-popular <code>misc.rs</code>. Everything compiled. Nothing made sense.</p> <p>Most Rust tutorials stop at “put your code in <code>main.rs</code> and maybe <code>lib.rs</code>.” That works for a CLI tool or a weekend project. It completely falls apart when you’ve got a team of eight engineers building a platform with multiple services, shared domain logic, and infrastructure that’s evolving every sprint.</p> </article> <article> <h1>Lesson 7: Repository Pattern — Abstracting storage</h1> <p>Mon, 13 Oct 2025 13:45:00 +0000</p> <p>Every backend developer eventually writes the same code: a function that takes a database connection, runs a query, maps the rows to a struct, and returns it. Then you write another one. And another. Pretty soon your business logic is tangled up with SQL strings and connection pool handles, and testing anything requires a running database.</p> <p>The Repository pattern fixes this. It’s old — Martin Fowler wrote about it in 2002 — but the way Rust implements it is genuinely different from what you’d do in Java or C#. Rust’s trait system, combined with generics and lifetimes, gives you a repository abstraction that’s zero-cost in production and trivially mockable in tests.</p> </article> <article> <h1>Lesson 6: Factory Patterns — When constructors aren't enough</h1> <p>Sat, 11 Oct 2025 10:00:00 +0000</p> <p>Here’s a hot take: most “Factory pattern” usage in Java and C# exists purely to work around limitations of constructors. Constructors can’t have descriptive names. They can’t return a different subtype. They can’t fail gracefully. So you wrap them in a static method and call it a Factory.</p> <p>Rust doesn’t have constructors at all. Every struct is constructed directly, and associated functions already do what Factory Method does in OOP. So do you even need the Factory pattern in Rust?</p> </article> <article> <h1>Lesson 5: Decorator Pattern — Wrapping with trait composition</h1> <p>Thu, 09 Oct 2025 16:30:00 +0000</p> <p>I remember the moment Decorator clicked for me. I was reading the source for Java’s I/O library — <code>BufferedInputStream</code> wrapping <code>FileInputStream</code> wrapping <code>InputStream</code>. Three layers deep, each adding behavior without subclassing. Elegant. Then I tried to write the same thing in Rust and learned that “wrapping a thing while preserving its interface” is a fundamentally different exercise when you don’t have inheritance.</p> <p>The good news? Rust’s version is often <em>better</em> than the OOP original, because composition is the default and the compiler enforces the contracts.</p> </article> <article> <h1>Lesson 17: Go Scheduler Behavior — M:N scheduling is not magic</h1> <p>Wed, 08 Oct 2025 00:00:00 +0000</p> <p>Most Go developers write concurrent code for years without thinking about the scheduler. That’s by design — the scheduler is supposed to be invisible. But eventually you’ll hit a situation where goroutines aren’t running when you expect them to, CPU cores are idle while goroutines pile up, or a CPU-bound workload is somehow slower with more goroutines. At that point you need a mental model of what’s actually happening under the hood.</p> </article> <article> <h1>Lesson 4: Command Pattern — Closures as commands</h1> <p>Tue, 07 Oct 2025 09:20:00 +0000</p> <p>The Command pattern has always struck me as one of those patterns that’s really just “wrap a function call in an object.” In Java, you create a <code>Command</code> interface with an <code>execute()</code> method, make a class for each command, and pass them around. It takes about 40 lines of boilerplate to do what a lambda does in one.</p> <p>In Rust, closures <em>are</em> the Command pattern. But when you need undo, history, or serialization, you still need the structured version — and Rust’s ownership model makes the undo/redo part surprisingly elegant.</p> </article> <article> <h1>Lesson 3: Multiple Return Values — Go functions don't hide their failures</h1> <p>Mon, 06 Oct 2025 00:00:00 +0000</p> <p>In most languages, a function returns one thing and communicates failure through a side channel — an exception, a null, a magic sentinel value. Go’s approach is different: functions can return multiple values, and the convention is to use that to make failure explicit in the signature itself. Once you’ve used it for a while, hiding failures in side channels starts to feel dishonest.</p> <h2 id="the-problem">The Problem</h2> <p>Sentinel values are the old-school way to signal failure from a function. You pick some value that “shouldn’t” appear in normal results and treat it as an error signal:</p> </article> <article> <h1>Lesson 3: Observer Pattern — Channels and callbacks in Rust</h1> <p>Sun, 05 Oct 2025 11:45:00 +0000</p> <p>The Observer pattern is where Rust’s ownership model gets <em>really</em> opinionated. In C# or Java, Observer is simple — maintain a list of listeners, call a method on each when something happens. But “a list of mutable references to objects that can be called at any time” is basically everything Rust’s borrow checker exists to prevent. So how do you do event-driven programming in Rust? You have more options than you’d think, and some of them are better than what OOP languages offer.</p> </article> <article> <h1>Lesson 29: State Machine DP — Track what state you're in</h1> <p>Sat, 04 Oct 2025 00:00:00 +0000</p> <p>Most DP problems have a clean one-dimensional state: position in an array, remaining capacity, current index. State machine DP adds another dimension that isn’t just a number — it’s a <em>mode</em> or <em>status</em> that your system is in. “Am I currently holding a stock? Am I in a cooldown period? Which color did I just paint the last house?”</p> <p>The stock trading problems are the canonical example. LeetCode has an entire series of them (I, II, III, IV, with Cooldown, with Transaction Fee) that all share the same structure but add constraints one by one. Solving them all with the same mental framework is satisfying once the state machine clicks.</p> </article> <article> <h1>Lesson 2: Strategy Pattern — Trait objects and generics</h1> <p>Fri, 03 Oct 2025 14:15:00 +0000</p> <p>In my first real Go project, I wrote an interface for a payment processor. Two implementations — Stripe and PayPal. Simple polymorphism. When I tried the same thing in Rust, the compiler hit me with a wall of errors about <code>dyn</code>, <code>Box</code>, object safety, and sized types. It took me a full afternoon to understand what was happening. The Strategy pattern — which is trivial in most OOP languages — forced me to actually understand Rust’s type system. And I came out the other side a better programmer for it.</p> </article> <article> <h1>Lesson 8: Runtime Comparison — Tokio vs async-std vs smol vs glommio</h1> <p>Thu, 02 Oct 2025 16:55:31 +0000</p> <p>Every few months, someone asks me “which async runtime should I use?” and every time my answer is frustrating: “it depends.” But after spending the last seven lessons understanding how runtimes work from the inside, we can finally have a real conversation about what the differences actually are, why they exist, and when each one is the right choice.</p> <p>I’ve used all four of these runtimes in production. Tokio for most things, smol for a lightweight embedded project, glommio for a storage engine prototype, and async-std briefly before migrating away from it. Let me share what I’ve learned — not from reading documentation, but from debugging real problems at 2 AM.</p> </article> <article> <h1>Lesson 4: The Repository Pattern — Sometimes a function is enough</h1> <p>Thu, 02 Oct 2025 00:00:00 +0000</p> <p>The repository pattern is one of those ideas that sounds great in an architecture talk and causes real pain when applied indiscriminately to a Go codebase. I’ve seen teams add a <code>UserRepository</code> interface with five methods, a concrete <code>postgresUserRepository</code> implementation, and a <code>mockUserRepository</code> for tests — and then wonder why everything takes three times as long to write. I’ve also seen teams skip the pattern entirely and end up with <code>*sql.DB</code> threaded through 40 different functions, impossible to test without a real database.</p> </article> <article> <h1>Lesson 1: Builder Pattern — Typestate builders and compile-time validation</h1> <p>Wed, 01 Oct 2025 08:30:00 +0000</p> <p>I once spent three days debugging a production outage caused by a builder that silently accepted a missing <code>host</code> field and defaulted to <code>localhost</code>. In Java. The builder compiled fine, the tests passed — because they ran against localhost — and the deployment connected to nothing. That was the day I stopped trusting optional fields in builders.</p> <p>Rust’s type system lets you make that entire category of bug impossible. Not at runtime. Not with validation methods. At <em>compile time</em>.</p> </article> <article> <h1>Lesson 29: sync.Cond — The coordination primitive nobody teaches</h1> <p>Wed, 01 Oct 2025 00:00:00 +0000</p> <p>Every Go concurrency course covers goroutines, channels, mutexes, WaitGroups, and maybe semaphores. Very few touch <code>sync.Cond</code>. It’s either treated as advanced or dismissed as unnecessary because “just use channels.” But there’s a whole class of coordination problem where channels are the wrong tool and <code>sync.Cond</code> is exactly right. Once you see the pattern, you’ll recognize it everywhere — and you’ll stop reaching for <code>time.Sleep</code> polling loops when you shouldn’t.</p> <p>This is a bonus lesson. Not because the topic is minor, but because it builds on mutexes (Lesson 6) and you really need to understand lock ownership before <code>sync.Cond</code> clicks.</p> </article> <article> <h1>Lesson 7: Designing a Custom Async Runtime — When Tokio isn't enough</h1> <p>Tue, 30 Sep 2025 11:20:06 +0000</p> <p>A colleague once asked me, “Why would anyone build a custom async runtime when Tokio exists?” Fair question. Tokio is battle-tested, well-maintained, and fast. For 95% of use cases, it’s the right answer. But I’ve now been in three situations where it wasn’t — and each one taught me something about what a runtime actually does.</p> <p>The first was a latency-sensitive trading system where work-stealing’s cache invalidation was unacceptable. The second was an embedded system with no allocator. The third was a specialized database engine where we needed precise control over I/O scheduling. Each time, understanding how to build a runtime from the ground up saved the project.</p> </article> <article> <h1>Lesson 16: Atomic Operations — Lock-free when you can, mutex when you must</h1> <p>Mon, 29 Sep 2025 00:00:00 +0000</p> <p>The first time I looked at <code>sync/atomic</code>, it felt like a niche tool for systems programmers writing lock-free data structures. Turns out it’s one of the most practically useful packages in the standard library — and most Go developers reach for it way too late, after they’ve already built something with a mutex and then profiled it into submission.</p> <p>Atomic operations are CPU-level instructions that read or modify memory as a single, indivisible unit. There’s no scheduler window between the read and the write. That means multiple goroutines can operate on the same memory location without a lock — and without any blocking. When your shared state is a counter, a flag, or a single configuration value, atomics are almost always the right tool.</p> </article> <article> <h1>Lesson 6: Work-Stealing Schedulers — Balancing load across cores</h1> <p>Sat, 27 Sep 2025 13:45:50 +0000</p> <p>I once spent two days debugging a performance issue where our Tokio application was using four cores but only one was doing any work. Three threads were idle, one was pegged at 100%. The problem wasn’t Tokio’s scheduler — it was ours. We’d accidentally created a pattern where all tasks were spawned from and waking on the same thread, and nothing triggered work-stealing because the tasks completed too quickly.</p> <p>That experience taught me that you can’t treat the scheduler as a black box. If you understand how work-stealing works, you can design your task topology to take advantage of it. If you don’t, you’ll write code that accidentally defeats it.</p> </article> <article> <h1>Lesson 5: The Reactor Pattern — How Tokio actually works</h1> <p>Wed, 24 Sep 2025 09:27:13 +0000</p> <p>I read the Tokio source code on a Sunday afternoon, expecting to find something inscrutable. Layers of unsafe code, impenetrable abstractions, the kind of thing that makes you question your career choices. What I actually found was a clean, well-documented reactor implementation that I could follow. Not easily — but followably. The architecture is elegant once you see how the pieces connect.</p> <p>This lesson is about that architecture. Not Tokio’s API — you already know how to use <code>tokio::spawn</code> and <code>TcpStream</code>. This is about what happens <em>underneath</em> when you call those functions. The reactor pattern, the I/O driver, the timer wheel, and how they all feed into the executor.</p> </article> <article> <h1>Lesson 10: Dependent Type Tricks — Encoding constraints in types</h1> <p>Mon, 22 Sep 2025 15:50:00 +0000</p> <p>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 <em>real</em> 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.</p> <p>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.</p> </article> <article> <h1>Lesson 13: iota for Enums — Constants that count themselves</h1> <p>Mon, 22 Sep 2025 00:00:00 +0000</p> <p>Go doesn’t have a built-in enum keyword. What it has is <code>iota</code>, a constant counter that resets to zero at the start of each <code>const</code> block and increments with every constant declaration. It sounds underwhelming. In practice it gives you typed enums, bitmask permissions, and self-maintaining constant sequences — all without any runtime overhead.</p> <h2 id="the-problem">The Problem</h2> <p>The naive approach to enums in Go is plain integer constants or string constants. Both work, but neither gives you type safety:</p> </article> <article> <h1>Lesson 4: epoll/kqueue — Platform event loops</h1> <p>Sun, 21 Sep 2025 17:08:45 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 9: Proof Witnesses — Types as proofs</h1> <p>Fri, 19 Sep 2025 13:22:00 +0000</p> <p>The moment this clicked for me was when I was reviewing a crate that had a function signature like <code>fn process(data: &[u8], _proof: NonEmpty<'_>)</code>. That second argument carried <em>no data</em>. 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.</p> <p>Types as proofs. Once you see it, you can’t unsee it.</p> </article> <article> <h1>Lesson 3: io_uring — Zero-copy async I/O on Linux</h1> <p>Fri, 19 Sep 2025 10:33:08 +0000</p> <p>I ran a benchmark last year that genuinely surprised me. A simple TCP echo server using <code>io_uring</code> was handling 40% more connections per second than the same server on <code>epoll</code>, 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 <code>io_uring</code> as a curiosity and started treating it as the future of Linux I/O.</p> <p>If you’ve been building async runtimes on <code>epoll</code> (or even <code>kqueue</code> on macOS), <code>io_uring</code> changes the game completely. Let me show you why.</p> </article> <article> <h1>Lesson 28: Interval DP — Optimal strategy between boundaries</h1> <p>Fri, 19 Sep 2025 00:00:00 +0000</p> <p>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].</p> </article> <article> <h1>Lesson 15: Semaphores for Concurrency Limits — A channel with a size is a semaphore</h1> <p>Thu, 18 Sep 2025 00:00:00 +0000</p> <p>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 <em>slow down</em>. 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.</p> <p>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 <em>is</em> a semaphore, and that insight unlocks a whole class of resource-limiting patterns.</p> </article> <article> <h1>Lesson 2: Building a Minimal Executor — Your own async runtime</h1> <p>Wed, 17 Sep 2025 14:12:37 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 8: Sealed Traits — Closing extension points</h1> <p>Tue, 16 Sep 2025 09:38:00 +0000</p> <p>I was designing a public API for a parser library when I realized I had a problem. I wanted users to <em>use</em> my trait — call its methods, pass it as a bound — but I did <em>not</em> 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.</p> </article> <article> <h1>Lesson 1: Future Internals — Poll, Waker, Context</h1> <p>Mon, 15 Sep 2025 08:45:22 +0000</p> <p>I thought I understood Rust futures until I tried to implement one without <code>async</code>/<code>await</code>. Not a toy future that immediately returns <code>Ready</code>. 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.</p> <p>The <code>async</code>/<code>await</code> syntax is one of Rust’s great lies. It looks simple. It <em>feels</em> 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.</p> </article> <article> <h1>Lesson 7: Type-Level Programming — Computing with types</h1> <p>Sat, 13 Sep 2025 11:15:00 +0000</p> <p>There’s a moment in every Rust programmer’s journey where they look at <code>typenum</code> or some const-generics trick and think: “Wait, we’re doing <em>math</em> at compile time? With the <em>type checker</em>?” 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.</p> <p>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.</p> </article> <article> <h1>Lesson 6: Variance — Covariance, contravariance, invariance</h1> <p>Thu, 11 Sep 2025 16:42:00 +0000</p> <p>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.</p> <p>If you’ve ever had a lifetime error that made no sense, variance might be the missing piece.</p> </article> <article> <h1>Lesson 5: Existential Types — impl Trait in depth</h1> <p>Tue, 09 Sep 2025 07:28:00 +0000</p> <p>I used <code>impl Trait</code> 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 <em>how</em> it’s different unlocks patterns that are genuinely impossible with plain generics.</p> <p>Let me show you.</p> <h2 id="two-positions-two-meanings">Two Positions, Two Meanings</h2> <p><code>impl Trait</code> means completely different things depending on where you use it:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#75715e">// Argument position: "I accept any type that implements Iterator" </span></span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">count_items</span>(iter: <span style="color:#a6e22e">impl</span> Iterator<span style="color:#f92672"><</span>Item <span style="color:#f92672">=</span> <span style="color:#66d9ef">i32</span><span style="color:#f92672">></span>) -> <span style="color:#66d9ef">usize</span> { </span></span><span style="display:flex;"><span> iter.count() </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#75715e">// Return position: "I return some specific type that implements Iterator, </span></span></span><span style="display:flex;"><span><span style="color:#75715e">// but I'm not telling you which one" </span></span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">make_numbers</span>() -> <span style="color:#a6e22e">impl</span> Iterator<span style="color:#f92672"><</span>Item <span style="color:#f92672">=</span> <span style="color:#66d9ef">i32</span><span style="color:#f92672">></span> { </span></span><span style="display:flex;"><span> (<span style="color:#ae81ff">0</span><span style="color:#f92672">..</span><span style="color:#ae81ff">10</span>).filter(<span style="color:#f92672">|</span>x<span style="color:#f92672">|</span> x <span style="color:#f92672">%</span> <span style="color:#ae81ff">2</span> <span style="color:#f92672">==</span> <span style="color:#ae81ff">0</span>) </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>In argument position, the <em>caller</em> chooses the concrete type. In return position, the <em>function</em> chooses — and the caller can’t see what it picked. These are fundamentally different concepts from type theory.</p> </article> <article> <h1>Lesson 20: internal Package Is Underrated — Compiler-enforced privacy for free</h1> <p>Mon, 08 Sep 2025 00:00:00 +0000</p> <p>Go has two visibility levels: exported (starts with a capital letter) and unexported (doesn’t). Most engineers use only these two. But there’s a third option that the language gives you for free, and it’s more useful than most people realize. The <code>internal</code> directory enforces that certain packages can only be imported by code within your own module — and the compiler, not documentation or convention, does the enforcing.</p> <p>Exported symbols are API commitments. Once something is exported and external code is depending on it, changing it is a breaking change. The <code>internal</code> package is the escape hatch: share code across multiple packages in your own codebase without accidentally publishing an API surface you’ll have to maintain forever.</p> </article> <article> <h1>Lesson 4: Simulating Higher-Kinded Types in Rust — The workarounds</h1> <p>Sun, 07 Sep 2025 19:03:00 +0000</p> <p>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 <em>native</em> HKTs, that’s true. But the workarounds are surprisingly expressive, and with GATs (generic associated types) now stable, we can get <em>most</em> of what you’d want from HKTs in practice.</p> <p>Let me walk you through the problem, why it matters, and the patterns that let you work around it.</p> </article> <article> <h1>Lesson 3: Transactions That Don't Bite — Begin, defer rollback, commit</h1> <p>Sun, 07 Sep 2025 00:00:00 +0000</p> <p>Transactions are the part of database programming where “it’s fine most of the time” really isn’t good enough. A buggy SELECT just returns wrong data. A buggy transaction can leave your database in a half-written state — an order placed without inventory decremented, money debited without the transfer completing, a user created without their profile record. The bugs are subtle, often don’t manifest in testing, and only show up in production when two things happen at the same time.</p> </article> <article> <h1>Lesson 3: Session Types — Protocol safety at compile time</h1> <p>Fri, 05 Sep 2025 10:45:00 +0000</p> <p>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.</p> <p>Session types fix this. They encode the <em>entire communication protocol</em> in the type system — who sends what, in what order, and when. If you violate the protocol, your code doesn’t compile. Period.</p> </article> <article> <h1>Lesson 27: Knapsack Patterns — Pick or skip, that's the whole pattern</h1> <p>Fri, 05 Sep 2025 00:00:00 +0000</p> <p>Knapsack is one of those patterns that shows up in disguise constantly. You’ll see problems framed as “partition this array,” “find a subset with sum X,” “assign +/- signs to get target T” — and underneath each one is the same fundamental structure: for each item, decide whether to include it or exclude it.</p> <p>The standard 0/1 Knapsack is the reference problem. Every variant is a modification of it: different objective functions (count instead of max value), different constraints (exact sum instead of capacity), different item usage rules (unbounded instead of once). Once you internalize the base pattern, the variants fall into place.</p> </article> <article> <h1>Lesson 2: Advanced Typestate — Multi-state machines at compile time</h1> <p>Wed, 03 Sep 2025 14:17:00 +0000</p> <p>The first time I implemented a connection pool that <em>couldn’t</em> 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.</p> <p>This is the typestate pattern taken to its logical extreme. In Lesson 1 we saw the basics with <code>PhantomData</code> 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.</p> </article> <article> <h1>Lesson 14: errgroup for Structured Concurrency — All succeed or all cancel</h1> <p>Tue, 02 Sep 2025 00:00:00 +0000</p> <p>There’s a pattern that comes up constantly in backend services: make N concurrent calls, collect all their results, and if any one of them fails, cancel the rest and return the error. This is the “all succeed or all cancel” pattern — and before <code>errgroup</code>, implementing it correctly required a non-trivial amount of boilerplate involving <code>WaitGroup</code>, error channels, and manual context cancellation. People got it wrong often enough that <code>errgroup</code> was created specifically to handle it.</p> </article> <article> <h1>Lesson 1: Zero-Sized Types — PhantomData, () as design tools</h1> <p>Mon, 01 Sep 2025 08:32:00 +0000</p> <p>I remember staring at a struct definition in a library I was reading — it had a field of type <code>PhantomData<T></code> 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?</p> <p>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.</p> </article> <article> <h1>Lesson 8: ML Data Pipelines — polars and processing at speed</h1> <p>Sat, 30 Aug 2025 14:15:00 +0000</p> <p>Last quarter I inherited a Python data pipeline that prepared training data for our recommendation model. It processed 50 million rows. Took 3 hours. Used 64GB of RAM. Everyone accepted this as normal — “big data is slow.” I rewrote it in Rust with polars. Same data. 4 minutes. 6GB of RAM. My teammates thought I was lying until they ran it themselves.</p> <p>Polars isn’t just “pandas but faster.” It’s a fundamentally different approach to DataFrame operations — lazy evaluation, query optimization, true parallelism, and a Rust-native API that makes data pipeline code genuinely pleasant to write.</p> </article> <article> <h1>Lesson 7: On-Device Inference — ONNX Runtime and candle</h1> <p>Tue, 26 Aug 2025 07:49:00 +0000</p> <p>I run a sentiment analysis model on every support ticket that comes in. At first I used the OpenAI API — about 2 cents per ticket. Sounds cheap until you do the math: 10,000 tickets a day, $200/day, $6,000/month. For a model that classifies text into “positive,” “negative,” and “neutral.”</p> <p>Switched to a local ONNX model running on a $50/month VM. Same accuracy. Latency dropped from 300ms to 8ms. Cost dropped to roughly zero. Not every task needs GPT-4 — and Rust is arguably the best language for running models locally because you get C++ performance without the C++ pain.</p> </article> <article> <h1>Lesson 13: Timeouts Everywhere — Unbounded waits are production bugs</h1> <p>Tue, 26 Aug 2025 00:00:00 +0000</p> <p>I have a strongly held opinion about timeouts: if you’re making a network call, a database query, or waiting on any external resource without a timeout, you’ve written a production bug. It just hasn’t fired yet. The network will eventually hang. The database will eventually have a slow query. The external API will eventually stop responding. And when it does, your goroutine will wait. And wait. And wait — holding a connection, a file descriptor, a slot in your worker pool — until the process runs out of resources or someone restarts it.</p> </article> <article> <h1>Lesson 5: Implicit Interfaces — The best decoupling you'll never declare</h1> <p>Mon, 25 Aug 2025 00:00:00 +0000</p> <p>In Java or C#, you declare that a class implements an interface. You write <code>implements Runnable</code>, and the compiler ties that class to that interface forever. Go doesn’t work that way. A type satisfies an interface the moment it has the right methods — no declaration, no explicit relationship. This sounds like a minor syntactic difference, but it changes how you design systems in ways that compound over time.</p> <h2 id="the-problem">The Problem</h2> <p>When interfaces are declared by the implementor (the Java way), you end up with a few recurring problems.</p> </article> <article> <h1>Lesson 6: Building MCP Servers in Rust — Model Context Protocol</h1> <p>Fri, 22 Aug 2025 10:23:00 +0000</p> <p>The first time I heard about MCP, I dismissed it as yet another protocol nobody would adopt. Then Claude Desktop shipped with MCP support, then Cursor, then Windsurf, then half the AI tools I use daily. Turns out when Anthropic publishes a spec and immediately supports it in their flagship products, adoption happens fast.</p> <p>MCP — Model Context Protocol — is a standardized way for AI models to discover and use tools, access data sources, and interact with external systems. Think of it as USB for AI: a universal interface so models don’t need custom integrations for every data source. And Rust is a fantastic language for building MCP servers because they need to be fast, reliable, and run for a long time without leaking memory.</p> </article> <article> <h1>Lesson 5: Agent Architectures in Rust — ReAct, planning, and loops</h1> <p>Wed, 20 Aug 2025 13:08:00 +0000</p> <p>I built my first “AI agent” by stuffing a system prompt into a while loop and hoping for the best. It worked — sometimes. Other times it’d get stuck in infinite loops, burn through $50 of API credits hallucinating tool calls that didn’t exist, or confidently produce completely wrong answers after three rounds of “reasoning.”</p> <p>The problem wasn’t the LLM. The problem was me treating agent design as an afterthought. Good agents need structure — clear state machines, well-defined stopping conditions, and guardrails that prevent runaway behavior. This is where Rust’s type system pays massive dividends, because you can encode these constraints at the type level.</p> </article> <article> <h1>Lesson 26: DP on Trees — Post-order traversal meets memoization</h1> <p>Wed, 20 Aug 2025 00:00:00 +0000</p> <p>Tree DP is the pattern that catches people by surprise. You’ve been thinking of DP as filling a 1D or 2D table from left to right — a sequential, iterative process. Trees are recursive by nature. The “table” is implicit in the call stack.</p> <p>The key insight: tree DP is just post-order traversal where each node computes its answer from its children’s answers. There’s no explicit table. The memoization (if you need it) is keyed by node pointer. The bottom-up order is inherently satisfied because post-order visits children before parents.</p> </article> <article> <h1>Lesson 8: Reproducible Builds — Same source, same binary</h1> <p>Mon, 18 Aug 2025 15:25:00 +0000</p> <p>A security auditor once asked me to prove that the binary running in production was actually built from the source code we claimed. I confidently ran <code>cargo build --release</code>, compared the hash of the output with the deployed binary, and… they were different. Same source, same compiler, same machine, different binary. That’s when I learned that reproducible builds aren’t automatic — even in Rust.</p> <h2 id="why-reproducible-builds-matter">Why Reproducible Builds Matter</h2> <p>A reproducible build means: given the same source code, same dependencies, same compiler, and same configuration, you get a bit-for-bit identical binary every time, on any machine.</p> </article> <article> <h1>Lesson 4: Embeddings and Vector Search — Semantic search in Rust</h1> <p>Mon, 18 Aug 2025 08:55:00 +0000</p> <p>I spent a week building a keyword search system for internal documentation. Regex patterns, stemming, tf-idf scoring — the whole nine yards. Then someone searched “how do I deploy” and got zero results because every doc said “deployment process” instead of “deploy.” That’s when I switched to embeddings.</p> <p>Embeddings map text into high-dimensional vectors where semantically similar content lives close together. “Deploy” and “deployment process” end up near each other in vector space even though they share almost no characters. It’s a fundamentally different approach to search, and once you’ve used it, keyword search feels like the dark ages.</p> </article> <article> <h1>Lesson 3: Tool Calling / Function Calling Patterns — Agents need tools</h1> <p>Sat, 16 Aug 2025 16:42:00 +0000</p> <p>Here’s something that took me embarrassingly long to internalize: LLMs don’t <em>do</em> things. They generate text that <em>describes</em> doing things. The tool calling protocol is just the model saying “hey, I’d like you to call this function with these arguments” — and then your code actually does it.</p> <p>This distinction matters because the entire tool calling system is essentially a serialization contract. The model generates JSON conforming to a schema you provided, you execute the function, and you send the result back. Get the schema wrong, and the model hallucinates arguments. Get the execution wrong, and you’ve got a broken agent. Get the result format wrong, and the model can’t make sense of what happened.</p> </article> <article> <h1>Lesson 7: Linking Strategies — Static, dynamic, LTO</h1> <p>Fri, 15 Aug 2025 10:40:00 +0000</p> <p>I deployed a Rust service to a minimal Docker container once — Alpine Linux, nothing installed except the binary. It crashed immediately with “not a dynamic executable.” Turns out my binary was dynamically linked against glibc, but Alpine uses musl. I’d never thought about linking before that day. Now it’s one of the first things I configure on any new project.</p> <h2 id="what-linking-actually-is">What Linking Actually Is</h2> <p>When you write <code>cargo build</code>, the compiler doesn’t produce a binary directly. It produces object files — chunks of machine code for each compilation unit. The <em>linker</em> takes all those object files, plus any libraries you depend on, and stitches them together into a single executable.</p> </article> <article> <h1>Lesson 12: Leak Prevention — Every goroutine must have an exit</h1> <p>Fri, 15 Aug 2025 00:00:00 +0000</p> <p>Goroutine leaks are the memory leaks of concurrent Go. They’re slow, invisible, and tend to surface only under load — or worse, only after days of continuous running when the service has accumulated tens of thousands of stuck goroutines. I’ve debugged two production incidents that traced back to leaks in code that had been in production for months, completely unnoticed during normal load.</p> <p>The root cause is almost always the same: someone started a goroutine and didn’t give it a way to exit. Not a way to exit eventually — a way to exit in every possible code path.</p> </article> <article> <h1>Lesson 2: Streaming LLM Responses — SSE and WebSockets</h1> <p>Thu, 14 Aug 2025 11:37:00 +0000</p> <p>The first time I demoed an LLM-powered feature to stakeholders, I made the rookie mistake of using non-streaming responses. The CEO asked a question, hit enter, and stared at a blank screen for eight seconds. “Is it broken?” No — it was thinking. But by the time the response appeared, she’d already mentally moved on to the next agenda item.</p> <p>Streaming changes everything. Users see tokens appearing in real-time, which feels responsive even when the total generation time is identical. But implementing streaming in Rust? It’s one of those things that’s surprisingly nuanced once you get past the happy path.</p> </article> <article> <h1>Lesson 6: Monorepo Management with Workspaces — Scaling Rust projects</h1> <p>Tue, 12 Aug 2025 13:10:00 +0000</p> <p>Our Rust project started as a single crate. Then we split the API handlers from the domain logic. Then we extracted shared types. Then someone added a CLI tool. Then a worker service. Before we knew it, we had nine crates and <code>cargo build</code> was doing weird things because three of them depended on different versions of <code>serde</code>. That’s when we sat down and properly set up a workspace.</p> <p>I’ve now managed Rust workspaces ranging from 5 crates to over 40. The patterns I’m going to share come from real mistakes — dependency hell, circular imports, CI builds that took 45 minutes, the works.</p> </article> <article> <h1>Lesson 1: Building LLM API Clients in Rust — Type-safe AI calls</h1> <p>Tue, 12 Aug 2025 09:14:00 +0000</p> <p>Last month I watched a coworker’s Python script silently swallow a malformed response from the OpenAI API. The <code>choices</code> field came back empty, the code plowed ahead with <code>choices[0]</code>, and the whole pipeline crashed at 2 AM. Nobody got paged because the error handler was also broken. Classic.</p> <p>That’s the moment I decided to rebuild our LLM integration layer in Rust. Not because I’m some Rust evangelist who thinks Python is evil — I use Python daily. But when you’re making API calls that cost real money and feed into production systems, maybe you want a type system that actually catches things before runtime.</p> </article> <article> <h1>Lesson 15: Goroutines Are Cheap, Not Free — 2KB that can eat your server</h1> <p>Mon, 11 Aug 2025 00:00:00 +0000</p> <p>“Goroutines are cheap” is something you read in every Go introduction. It’s true. A goroutine starts with a 2KB stack and the runtime handles scheduling. Spinning up a thousand of them is trivial. The part the introductions leave out is that “cheap” is not “free,” and goroutines that you start and never stop are a leak — one that doesn’t crash your program, just slowly eats your memory and degrades your scheduler until something gives.</p> </article> <article> <h1>Lesson 5: Code Generation — proc macros, build.rs, xtask</h1> <p>Sun, 10 Aug 2025 08:55:00 +0000</p> <p>I once inherited a codebase where someone had written a Python script that generated 4,000 lines of Rust from a YAML spec. The script ran outside of Cargo, the generated file was checked into git, and nobody remembered to re-run it when the spec changed. By the time I found it, the generated code and the spec had diverged in twelve places. That experience shaped how I think about code generation in Rust — it needs to be integrated into the build, not bolted on the side.</p> </article> <article> <h1>Lesson 25: DP on Strings — Palindromes and partitions</h1> <p>Sat, 09 Aug 2025 00:00:00 +0000</p> <p>String DP has its own flavor that’s distinct from the two-string comparison problems of the last lesson. Here, the state is typically a single string, but the subproblem is about a <em>range</em> within that string: “what’s the answer for the substring s[i..j]?” That’s interval DP applied to strings, and palindromes are its most natural setting.</p> <p>The tricky part with palindrome problems is that you can approach them from the outside in (is s[i..j] a palindrome?) or the inside out (expand from a center). DP works from the outside in: small intervals first, then build up to larger ones. The expansion approach is often faster in practice but DP is more general and extends to partition problems naturally.</p> </article> <article> <h1>Lesson 12: Production Systems Software — Databases, runtimes, proxies</h1> <p>Fri, 08 Aug 2025 09:33:27 +0000</p> <p>I’ve been building systems software professionally for a while now, and here’s what I’ve noticed: the skills we’ve covered in this course — <code>no_std</code> programming, memory-mapped I/O, custom allocators, interrupt handlers, network protocols — they all converge when you build production systems software. A database engine is just a file system on top of a storage engine with a query processor. A network proxy is packet parsing plus connection management. A language runtime is memory management plus a scheduler.</p> </article> <article> <h1>Lesson 2: Connection Pool Tuning — Your pool config is probably wrong</h1> <p>Fri, 08 Aug 2025 00:00:00 +0000</p> <p>Here’s a scenario that played out for me once: service is running fine for weeks, then we double traffic, and suddenly requests start timing out. Not all of them — maybe 10%. The logs show <code>pq: sorry, too many clients already</code>. Postgres is refusing connections. But we have a connection pool — that’s the whole point, right? Why is Postgres seeing more connections than it can handle?</p> <p>Because <code>database/sql</code>’s default pool settings are almost certainly wrong for production, and most people never change them.</p> </article> <article> <h1>Lesson 4: Custom Lints with clippy and dylint — Your team's rules</h1> <p>Thu, 07 Aug 2025 16:20:00 +0000</p> <p>We had this rule on my old team: never use <code>.unwrap()</code> on database query results. We wrote it in our contributing guide. We mentioned it in code reviews. We added it to the onboarding doc. And yet, every single sprint, someone would push an <code>.unwrap()</code> on a <code>sqlx::Result</code> that would blow up in production at 2 AM. That’s when I decided to make the compiler enforce our rules instead of relying on humans to remember them.</p> </article> <article> <h1>Lesson 3: Conditional Compilation — cfg, features, target</h1> <p>Tue, 05 Aug 2025 11:45:00 +0000</p> <p>A few months back I was debugging a test failure that only happened on our Linux CI server, never on my Mac. Turns out someone had written platform-specific file path handling without proper <code>cfg</code> guards — the code compiled fine on both platforms but silently did the wrong thing on Linux. That’s when I really internalized why conditional compilation needs to be treated as a first-class skill, not something you google when you need it.</p> </article> <article> <h1>Lesson 11: Building a Minimal Hypervisor — Virtualization in Rust</h1> <p>Mon, 04 Aug 2025 15:42:18 +0000</p> <p>The first time I watched a virtual machine boot — not using VirtualBox, but running inside a hypervisor <em>I’d written</em> — I had the same feeling as when my bootloader printed its first character. Except this time, I wasn’t just running code on bare metal. I was creating a <em>fake machine</em> that thought it was running on bare metal.</p> <p>Virtualization is where systems programming hits its ceiling of complexity. You’re manipulating the CPU’s hardware virtualization extensions to create isolated execution environments. It’s also where Rust’s safety guarantees become most valuable — because a bug in a hypervisor doesn’t just crash your program, it potentially compromises every virtual machine running on the host.</p> </article> <article> <h1>Lesson 2: build.rs — Code generation at compile time</h1> <p>Sun, 03 Aug 2025 14:30:00 +0000</p> <p>The first time I needed <code>build.rs</code>, I was wrapping a C library that had about 200 constants defined in a header file. I could’ve copied them all by hand into Rust <code>const</code> declarations. Instead, I wrote a build script that parsed the header and generated the constants automatically. Took 30 minutes to write the build script, and it saved me from maintaining a manual mapping that would’ve drifted out of sync within a month.</p> </article> <article> <h1>Lesson 11: Graceful Shutdown — Stop accepting, finish what you started</h1> <p>Sun, 03 Aug 2025 00:00:00 +0000</p> <p>Most Go services handle startup carefully and shutdown carelessly. The startup code has retries, health checks, dependency validation. The shutdown code is <code>os.Exit(0)</code> or — if the developer was feeling generous — nothing at all, just letting the process get killed. That’s how you get dropped HTTP connections, half-written database records, uncommitted Kafka offsets, and on-call alerts at 3am.</p> <p>Graceful shutdown has one principle: stop accepting new work, finish what you already started. That’s it. But implementing it correctly requires knowing the shutdown order, wiring up OS signals properly, and draining workers before pulling the plug.</p> </article> <article> <h1>Lesson 10: Writing a Bootloader — The first code that runs</h1> <p>Fri, 01 Aug 2025 22:10:44 +0000</p> <p>There’s something almost spiritual about writing a bootloader. Your code is the <em>first thing that runs</em> on a machine. Before the OS. Before any drivers. Before the memory manager. Before anything. The CPU comes out of reset, fetches an instruction from a known address, and that instruction is yours.</p> <p>I spent a weekend writing one. By Sunday night, I had four characters on screen — <code>BOOT</code> — rendered by writing directly to VGA memory. And it felt like I’d conquered the world.</p> </article> <article> <h1>Lesson 1: Cargo Deep Dive — Workspaces, features, profiles</h1> <p>Fri, 01 Aug 2025 09:15:00 +0000</p> <p>I’d been writing Rust for about a year before I realized I was only using maybe 20% of what Cargo actually offers. <code>cargo build</code>, <code>cargo run</code>, <code>cargo test</code> — that was my entire workflow. Then I joined a team managing a Rust monorepo with 30+ crates, custom build profiles, and feature flags controlling everything from database backends to telemetry. Suddenly my surface-level Cargo knowledge wasn’t cutting it.</p> <h2 id="cargo-is-not-just-a-build-tool">Cargo Is Not Just a Build Tool</h2> <p>Most people coming from other languages think of Cargo as “npm for Rust” or “Maven for Rust.” That undersells it massively. Cargo is a build system, package manager, test runner, benchmark runner, documentation generator, and project convention enforcer — all rolled into one binary. And unlike most build tools, it’s actually pleasant to use.</p> </article> <article> <h1>Lesson 9: Interrupt Handlers and Real-Time Constraints — When timing matters</h1> <p>Wed, 30 Jul 2025 06:55:22 +0000</p> <p>I once spent three days debugging a motor controller that would randomly twitch. The code was correct. The hardware was fine. The interrupt handler was well-written. But every few thousand cycles, a timer interrupt would preempt the motor control interrupt at exactly the wrong moment, corrupting a shared variable. The fix was two lines of code — disable interrupts around the critical section — but finding it cost me a weekend.</p> </article> <article> <h1>Lesson 23: Error Values, Not Exceptions — Errors you can actually inspect</h1> <p>Mon, 28 Jul 2025 00:00:00 +0000</p> <p>In most languages, errors are events — they get thrown, they propagate up the call stack, and you catch them somewhere above. Go rejects this model entirely. In Go, an error is a value, just like an integer or a string. You pass it around, inspect it, wrap it with context, and check it right where it happens. Ignore it and your code doesn’t crash loudly; it quietly does the wrong thing, and you’ll find out at the worst possible moment.</p> </article> <article> <h1>Lesson 8: Designing Custom Allocators — Beyond the global allocator</h1> <p>Sun, 27 Jul 2025 13:19:56 +0000</p> <p>Here’s a dirty secret of systems programming: <code>malloc</code> is not magic. It’s just code. Code that somebody wrote, code that makes tradeoffs, and code you can replace when those tradeoffs don’t match your workload.</p> <p>I spent two years writing performance-sensitive Rust before I realized that the global allocator was my bottleneck. Not CPU. Not I/O. Memory allocation — thousands of tiny allocations per request, each one hitting a lock, each one fragmenting the heap a little more. Switching to a bump allocator for request-scoped data cut latency by 40%.</p> </article> <article> <h1>Lesson 7: Implementing Network Protocols — TCP from scratch</h1> <p>Thu, 24 Jul 2025 10:31:48 +0000</p> <p>I thought I understood TCP until I tried to implement it. Turns out, “client connects to server, data flows” is about 5% of the story. The other 95% is state machines, retransmission timers, congestion windows, and edge cases that would make your head spin.</p> <p>But here’s the good news: implementing even a simplified TCP teaches you more about networking than any textbook. And Rust’s type system is actually perfect for modeling protocol state machines — states become types, invalid transitions become compile errors.</p> </article> <article> <h1>Lesson 24: 2D DP Advanced — String comparison is always 2D DP</h1> <p>Thu, 24 Jul 2025 00:00:00 +0000</p> <p>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.</p> <p>The structure is always the same: <code>dp[i][j]</code> 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.</p> </article> <article> <h1>Lesson 6: Building a File System — From blocks to files</h1> <p>Tue, 22 Jul 2025 16:08:32 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 5: OS Concepts in Rust — Processes, threads, signals</h1> <p>Sat, 19 Jul 2025 07:45:19 +0000</p> <p>I used to think I understood processes. Then I tried to implement <code>fork()</code> semantics in Rust and realized I’d been cargo-culting UNIX concepts for years without actually understanding what was happening underneath.</p> <p>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.</p> </article> <article> <h1>Lesson 8: The Component Model — Composable WASM modules</h1> <p>Fri, 18 Jul 2025 10:41:09 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 4: Writing Linux Kernel Modules in Rust — Rust in the kernel</h1> <p>Thu, 17 Jul 2025 11:23:45 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 10: Pipelines and Stage Isolation — Each stage owns its output channel</h1> <p>Thu, 17 Jul 2025 00:00:00 +0000</p> <p>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.</p> </article> <article> <h1>Lesson 7: WASI — WebAssembly beyond the browser</h1> <p>Tue, 15 Jul 2025 19:22:41 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 3: Memory-Mapped I/O — Talking to hardware</h1> <p>Mon, 14 Jul 2025 19:52:07 +0000</p> <p>There’s a moment in every systems programmer’s life when they realize that writing to memory address <code>0x4002_0818</code> 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.</p> <p>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 <em>correct</em>.</p> </article> <article> <h1>Lesson 1: Error Handling — Your code is lying if it ignores errors</h1> <p>Mon, 14 Jul 2025 00:00:00 +0000</p> <p>If you’re coming from Python, Java, or JavaScript, Go’s error handling will feel strange at first. There’s no <code>try/catch</code>. 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.</p> <h2 id="the-problem">The Problem</h2> <p>The blank identifier <code>_</code> is the most dangerous character in Go. Here’s what it looks like when engineers first start writing Go:</p> </article> <article> <h1>Lesson 6: Multi-Threaded WASM — SharedArrayBuffer and atomics</h1> <p>Sun, 13 Jul 2025 07:55:18 +0000</p> <p>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.</p> <p>The bad news? Getting threads working in WASM is more involved than <code>std::thread::spawn</code>. 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.</p> </article> <article> <h1>Lesson 23: 2D DP Basics — Two dimensions, one table</h1> <p>Sun, 13 Jul 2025 00:00:00 +0000</p> <p>1D DP was a single row — you filled it left to right and you were done. 2D DP extends that to a full table. You fill it row by row, and each cell depends on cells above it, to its left, or diagonally above-left. The shape of that dependency is the shape of the problem.</p> <p>I find 2D DP more intuitive than 1D once I got comfortable with the table visualization. Unique Paths is a perfect first problem because you can literally draw the grid and fill it in by hand in 30 seconds. Edit Distance is the crown jewel — once you understand why the three transitions correspond to the three edit operations, you’ll never forget the recurrence.</p> </article> <article> <h1>Lesson 2: Embedded Rust — Microcontrollers and bare metal</h1> <p>Sat, 12 Jul 2025 14:37:51 +0000</p> <p>I bricked my first development board within forty-five minutes of getting it out of the box. Wrote some C code, forgot to configure the clock properly, flashed it, and the thing just… stopped responding. No debugger connection. No serial output. A $15 paperweight.</p> <p>That experience — the raw, unforgiving nature of hardware programming — is exactly why Rust matters in embedded. Not because it prevents you from writing to the wrong register (it can’t, really), but because it gives you tools to <em>structure</em> hardware access so mistakes become harder to make.</p> </article> <article> <h1>Lesson 5: WASM Performance — When it beats JavaScript</h1> <p>Thu, 10 Jul 2025 16:08:51 +0000</p> <p>“WASM is faster than JavaScript.” I’ve heard this so many times, and it drives me nuts — not because it’s wrong, but because it’s incomplete. WASM <em>can</em> be faster than JavaScript. It can also be slower. The difference depends on what you’re doing, how you’re crossing the JS↔WASM boundary, and whether you’ve hit the specific scenarios where WASM’s architecture actually gives you an advantage.</p> <p>I ran benchmarks for months to figure out where the real boundaries are. Let me show you the data.</p> </article> <article> <h1>Lesson 1: no_std — Rust without the standard library</h1> <p>Thu, 10 Jul 2025 08:14:33 +0000</p> <p>The first time I tried to compile a Rust program with <code>#![no_std]</code>, I felt like someone had pulled the floor out from under me. No <code>println!</code>. No <code>String</code>. No <code>Vec</code>. No <code>HashMap</code>. Half the stuff I relied on daily — just <em>gone</em>.</p> <p>And that’s exactly the point.</p> <h2 id="why-would-anyone-do-this">Why Would Anyone Do This?</h2> <p>Here’s the thing most Rust tutorials won’t tell you up front: the standard library is <em>enormous</em>. It pulls in heap allocation, threading, file I/O, networking, and a whole OS-level runtime. That’s great for application development. It’s a non-starter for:</p> </article> <article> <h1>Lesson 6: Agent Architectures — Building autonomous agents in Go</h1> <p>Thu, 10 Jul 2025 00:00:00 +0000</p> <p>An agent is a loop: observe, think, act, repeat. The LLM is the “think” step — it decides what to do next given the current state. Your Go code handles “observe” (gathering context), “act” (executing tool calls), and the loop control that keeps everything running. I’ve built agents that write and execute code, agents that browse the web, and agents that orchestrate multi-step data pipelines. The underlying architecture is always the same few patterns, and Go’s concurrency makes the execution layer clean and fast.</p> </article> <article> <h1>Lesson 9: Worker Pools — Bounded concurrency or bust</h1> <p>Thu, 10 Jul 2025 00:00:00 +0000</p> <p>Production Go codebases that run fine in staging will sometimes crater under real traffic. More often than not, the cause is unbounded goroutine creation. Some background job processor spins up a goroutine per message. The queue backs up. Suddenly there are 50,000 goroutines fighting for CPU, exhausting file descriptors, allocating gigabytes of stack space. The service falls over. The incident post-mortem says “we didn’t expect this load.” The real cause: no worker pool.</p> </article> <article> <h1>Lesson 1: database/sql Done Right — The stdlib is better than you think</h1> <p>Tue, 08 Jul 2025 00:00:00 +0000</p> <p>I spent a long time reaching for third-party database libraries in Go before I actually read the <code>database/sql</code> docs. When I finally did, I was embarrassed — the stdlib had everything I needed and I’d been adding dependencies for no reason. The problem isn’t that <code>database/sql</code> is limited. The problem is that it has a handful of non-obvious behaviors that, if you don’t know about them, will burn you in production. Once you internalize those, you’ll write better database code than most people using ORMs.</p> </article> <article> <h1>Lesson 4: Leptos, Yew, Dioxus — Full-stack Rust</h1> <p>Mon, 07 Jul 2025 09:17:33 +0000</p> <p>After building that todo list with raw <code>web-sys</code> in Lesson 3, I think we can all agree: manually managing DOM nodes, closures wrapped in <code>Rc<RefCell<Option<Closure<dyn FnMut()>>>></code>, and string-based style attributes isn’t how anyone wants to build a real application. That’s where Rust frontend frameworks come in. And we’ve got three serious contenders — each with a different philosophy about how to build web UIs.</p> <p>I’ve built side projects with all three. Let me tell you what actually matters when choosing between them.</p> </article> <article> <h1>Lesson 3: Manipulating the DOM from Rust — Web without JavaScript</h1> <p>Sat, 05 Jul 2025 11:33:47 +0000</p> <p>There’s something deeply satisfying about writing <code>document.create_element("div")</code> in Rust and watching it actually work in a browser. It’s also, if I’m being honest, kind of painful — because <code>web-sys</code> wraps every single Web API call in <code>Result</code> types, and you end up with <code>.unwrap()</code> chains that would make any Rustacean cringe. But once you build the right abstractions on top, it becomes surprisingly pleasant. Let me show you how I got there.</p> </article> <article> <h1>Lesson 8: strings and bytes Builders — Stop concatenating in loops</h1> <p>Sat, 05 Jul 2025 00:00:00 +0000</p> <p>String concatenation with <code>+</code> is one of the most common performance bugs I see in Go code reviews. Not because developers are careless, but because the bug is invisible — the code looks clean and correct. <code>result += piece</code> is obvious. The quadratic memory behavior that follows is not.</p> <p>The <code>strings</code> and <code>bytes</code> packages are where Go provides the right tools for this job. <code>strings.Builder</code> and <code>bytes.Buffer</code> are both efficient for incremental string construction, but they’re not the same type and the choice between them matters in specific cases. Beyond building strings, these packages contain functions that have non-obvious but significant performance implications: <code>strings.Contains</code> vs <code>strings.Index</code>, <code>strings.Split</code> vs <code>strings.SplitN</code>, and the ones people reach for that they shouldn’t.</p> </article> <article> <h1>Lesson 10: Soundness — The ultimate safety guarantee</h1> <p>Fri, 04 Jul 2025 16:50:00 +0000</p> <p>A few months ago, someone filed a soundness bug against a crate I maintained. The report was elegant — three lines of safe code that triggered a use-after-free through my API. No <code>unsafe</code> in the caller’s code. The bug was in my <code>unsafe</code> implementation. I fixed it within the hour, cut a patch release, and filed a CVE advisory. That’s the social contract of soundness in Rust: if safe code can cause undefined behavior, the bug is <em>always</em> in the library.</p> </article> <article> <h1>Lesson 2: wasm-bindgen — Bridging Rust and JavaScript</h1> <p>Thu, 03 Jul 2025 14:12:05 +0000</p> <p>The first time I looked at what <code>#[wasm_bindgen]</code> actually generates, I was equal parts impressed and horrified. Impressed because it seamlessly bridges two fundamentally different type systems. Horrified because the generated code is a labyrinth of pointer arithmetic, descriptor tables, and heap management. But here’s the thing — you don’t need to understand every line of generated code. You do need to understand the <em>model</em>, because when things go wrong (and they will), the model is what helps you debug.</p> </article> <article> <h1>Lesson 10: Over-Engineering CRUD — Not every API needs a hexagonal architecture</h1> <p>Wed, 02 Jul 2025 00:00:00 +0000</p> <p>There is a category of service that I have built many times and will build many more times: an API that creates, reads, updates, and deletes records in a relational database, with some validation and authentication. There is nothing glamorous about it, and there is nothing architecturally complex about it either. The correct implementation is straightforward, fast to build, easy to test, and easy to read. The over-engineered implementation has event sourcing, CQRS, a message bus, six layers of abstraction, and takes three months to build something that the straightforward implementation would have shipped in two weeks.</p> </article> <article> <h1>Lesson 9: napi-rs — Rust extensions for Node.js</h1> <p>Tue, 01 Jul 2025 13:26:00 +0000</p> <p>We had a Node.js microservice that validated JWTs. Under load, the <code>jsonwebtoken</code> npm package was burning 40% of CPU on RSA signature verification. I wrote the verification in Rust with napi-rs, dropped it in as a replacement, and CPU usage fell to 8%. The JavaScript API didn’t change at all — same function name, same arguments, same return type. Just 5x faster.</p> <p>napi-rs is to Node.js what PyO3 is to Python. You write Rust, export it as a native Node addon, and call it from JavaScript like any other module. The framework handles all the N-API complexity, type marshaling, and async integration.</p> </article> <article> <h1>Lesson 1: Rust to WebAssembly — Why and how</h1> <p>Tue, 01 Jul 2025 08:45:22 +0000</p> <p>I was optimizing a client-side image processing pipeline last year — think heavy convolutions, histogram equalization, color space conversions. The JavaScript implementation was doing about 12 frames per second. I rewrote the core loops in Rust, compiled to WebAssembly, and hit 55 fps. Same browser. Same machine. That’s the moment WebAssembly stopped being a curiosity and became a tool I actually reach for.</p> <p>But let me be real: getting there wasn’t a straight line. The tooling has rough edges, the mental model is different from writing server-side Rust, and half the blog posts out there show you how to add two numbers in WASM and call it a tutorial. That’s not what we’re doing here.</p> </article> <article> <h1>Lesson 2: defer for Cleanup — Put the cleanup next to the mess</h1> <p>Mon, 30 Jun 2025 00:00:00 +0000</p> <p>Every time you open a file, acquire a lock, or start a database transaction, you’ve created a resource that needs to be released when you’re done with it. In most languages you manage this with <code>finally</code> blocks or RAII patterns. Miss one cleanup and you’ve got a leak. Go has <code>defer</code>, and once it clicks, you’ll wonder how you ever coded without it.</p> <h2 id="the-problem">The Problem</h2> <p>Here’s what resource cleanup looks like without <code>defer</code>. Real code, the kind that ships:</p> </article> <article> <h1>Lesson 8: PyO3 — Rust extensions for Python</h1> <p>Sat, 28 Jun 2025 08:14:00 +0000</p> <p>I had a Python service that processed 2 million JSON records daily. Profiling showed 80% of the time was spent in one function — a custom similarity scoring algorithm. I rewrote that single function in Rust with PyO3. Same API, same tests, same deployment. Processing time dropped from 47 minutes to 90 seconds. The Python team didn’t have to learn Rust, didn’t have to change their imports, didn’t even notice — they just saw their pipeline get 30x faster.</p> </article> <article> <h1>Lesson 22: 1D DP Advanced — When the state space gets interesting</h1> <p>Fri, 27 Jun 2025 00:00:00 +0000</p> <p>Climbing Stairs and House Robber have a comfortable property: <code>dp[i]</code> depends on just the previous one or two positions. Each step you take looks back a fixed distance. These are the training wheels problems.</p> <p>Advanced 1D DP breaks that comfort. Word Break needs to look back up to the entire string. LIS needs to look back at every prior element. Coin Change loops over all denominations at every position. The look-back window is variable, sometimes unbounded. The dp array is still 1D — but you need a loop inside a loop.</p> </article> <article> <h1>Lesson 7: Exposing Rust to C — cdylib and cbindgen</h1> <p>Wed, 25 Jun 2025 15:40:00 +0000</p> <p>A team I was advising had a massive C codebase — about 400,000 lines of networking code. They wanted to rewrite their TLS handling in Rust but couldn’t justify a full rewrite. The solution: build Rust as a shared library, expose a C-compatible API, and link it into the existing build. Took a week to get the first version working. The memory safety bugs in that module dropped to zero.</p> </article> <article> <h1>Lesson 8: Fan-Out / Fan-In — Distribute, collect, don''t leak</h1> <p>Tue, 24 Jun 2025 00:00:00 +0000</p> <p>There’s a moment in every Go developer’s journey where the serial loop stops being acceptable. You’ve got 200 URLs to fetch, 500 records to transform, 50 API calls to make — and you’re doing them one at a time. The fix feels obvious: spin up goroutines. But spin them up without a plan and you’ve traded one problem for three.</p> <p>Fan-out / fan-in is the pattern that makes parallel work manageable. Fan-out means distributing a stream of work across multiple goroutines. Fan-in means collecting their results into a single channel. Simple in concept, surprisingly easy to get wrong in practice.</p> </article> <article> <h1>Lesson 6: FFI — Calling C from Rust</h1> <p>Mon, 23 Jun 2025 11:55:00 +0000</p> <p>My first real FFI project was binding to SQLite. I thought “how hard can it be — it’s just calling C functions.” Three days later I was debugging a segfault caused by a string lifetime issue where Rust freed a <code>CString</code> while SQLite was still reading from the pointer. That experience taught me more about unsafe Rust than any tutorial ever could.</p> <p>Calling C from Rust is the most common FFI scenario. Every operating system API is C. Most high-performance libraries — OpenSSL, zlib, SQLite, libcurl — are C. If you’re writing systems software in Rust, you’ll need this skill.</p> </article> <article> <h1>Lesson 5: Building Safe Abstractions Over Unsafe Code — The encapsulation pattern</h1> <p>Fri, 20 Jun 2025 09:22:00 +0000</p> <p>The standard library’s <code>Vec<T></code> contains over 50 <code>unsafe</code> blocks. <code>HashMap</code> has even more. Yet you use both every day without thinking about safety — because their public APIs are entirely safe. The <code>unsafe</code> is invisible, encapsulated behind type system boundaries that make misuse impossible.</p> <p>This is the most important pattern in Rust: unsafe internals, safe surface. Master it, and you can build anything.</p> <h2 id="the-core-principle">The Core Principle</h2> <p>An <code>unsafe</code> block means “I’ve verified the invariants.” A safe API means “the type system prevents invariant violations.” The goal is to push all the verification into the implementation so that <em>users</em> of your code can’t break the invariants no matter what they do.</p> </article> <article> <h1>Lesson 10: The Complete Go Service — HTTP + DB + workers + shutdown in 200 lines</h1> <p>Fri, 20 Jun 2025 00:00:00 +0000</p> <p>Every lesson in this series has been a piece of a puzzle. HTTP routing, middleware, validation, error responses, pagination, idempotency, timeouts, rate limiting, config management — each one addresses a specific concern in isolation. This final lesson puts them together into a single, production-shaped service that you can actually use as a starting point.</p> <p>The goal is not a complete application. It is a skeleton that demonstrates how all the pieces wire together in <code>main.go</code> and what a well-structured Go service looks like before you add your business logic.</p> </article> <article> <h1>Lesson 4: transmute — Type punning and its dangers</h1> <p>Wed, 18 Jun 2025 17:08:00 +0000</p> <p>I once watched a senior engineer <code>transmute</code> a <code>Vec<u8></code> into a <code>Vec<u32></code> and couldn’t figure out why it segfaulted on ARM but worked fine on x86. Spoiler: alignment. The allocator returned 1-byte-aligned memory for the <code>u8</code> vec, and <code>u32</code> needs 4-byte alignment. On x86 you pay a performance penalty; on ARM you get a bus error.</p> <p><code>transmute</code> is Rust’s most powerful unsafe tool. It reinterprets the bits of one type as another type. No conversion, no transformation — just “these bytes are now a different type.” That power makes it incredibly useful and incredibly dangerous.</p> </article> <article> <h1>Lesson 6: API Gateway Patterns — One entry point, many backends</h1> <p>Wed, 18 Jun 2025 00:00:00 +0000</p> <p>The first time I connected a mobile frontend directly to 11 microservices, I created 11 places for the mobile team to integrate, 11 different auth schemes to understand, 11 different error formats to handle, and a situation where a single product screen required 6 parallel API calls because the data was spread across 6 services. An API gateway solves all of this: one URL, one auth scheme, one error format, and the ability to aggregate multiple service responses into a single response the client actually needs.</p> </article> <article> <h1>Lesson 8: Monolith-First — Modular monoliths in Rust</h1> <p>Tue, 17 Jun 2025 13:19:00 +0000</p> <p>I’m going to tell you something that might sound weird after seven lessons about microservices patterns: don’t start with microservices. Start with a monolith. A well-structured, modular monolith that’s <em>designed</em> to be split later.</p> <p>This isn’t contrarianism for its own sake. I’ve seen three teams build microservices from day one. All three regretted it. One team spent more time debugging distributed system issues than building features. Another had seven services that each handled about 50 requests per day — the infrastructure cost was absurd. The third discovered six months in that they’d drawn their service boundaries wrong and had to do a painful re-architecture.</p> </article> <article> <h1>Lesson 3: Dereferencing Raw Pointers Safely — The patterns that work</h1> <p>Mon, 16 Jun 2025 10:45:00 +0000</p> <p>A colleague once showed me a bug that took them three days to find. Their <code>unsafe</code> code dereferenced a pointer that was valid when created but dangling by the time it was used — a classic lifetime mismatch. The fix was two lines. The debugging was seventy-two hours. That ratio is why this lesson exists.</p> <p>Dereferencing raw pointers is the most common <code>unsafe</code> operation you’ll encounter, and getting it right means following specific patterns. Not guidelines — patterns. Repeatable, auditable approaches that make your <code>unsafe</code> code reviewable.</p> </article> <article> <h1>Lesson 14: context.Context — The parameter every function should take first</h1> <p>Mon, 16 Jun 2025 00:00:00 +0000</p> <p>Without <code>context.Context</code>, a function that makes a database call, fires an HTTP request, or runs a long computation has no way to be told to stop. The caller times out, the user closes the browser tab, the load balancer kills the connection — and your function keeps running, consuming CPU and holding database connections, doing work that nobody will ever see. <code>context.Context</code> is how Go solves this.</p> <h2 id="the-problem">The Problem</h2> <p>A function with no context cannot be cancelled. It runs until it finishes, or until the process dies. In an HTTP server handling hundreds of requests per second, this accumulates fast:</p> </article> <article> <h1>Lesson 8: Zero-Downtime Deploys — Rolling updates without dropping requests</h1> <p>Sun, 15 Jun 2025 00:00:00 +0000</p> <p>The first rolling deployment I did without graceful shutdown handling produced about 200 errors for in-flight requests. Kubernetes sent <code>SIGTERM</code> to the old pods, the Go process exited immediately, and every active request was terminated mid-flight. The users got 502s. The monitoring dashboard lit up red for about 30 seconds per deploy, every time.</p> <p>Kubernetes’s rolling update strategy replaces pods one at a time and can achieve zero request drops — but only if your application cooperates. The contract is: Kubernetes sends <code>SIGTERM</code>, your application finishes in-flight requests, then exits. If you ignore <code>SIGTERM</code> and exit immediately, Kubernetes kills you with <code>SIGKILL</code> after the grace period anyway, and you drop the requests. The work is in your application code, not in the Kubernetes config.</p> </article> <article> <h1>Lesson 2: Raw Pointers — *const T, *mut T and when you need them</h1> <p>Sat, 14 Jun 2025 14:17:00 +0000</p> <p>The first time I used raw pointers in Rust, I was porting a ring buffer from C. I’d written ring buffers in C a dozen times — head pointer, tail pointer, wrap around, done. In Rust, the borrow checker wanted nothing to do with my two mutable pointers into the same buffer. That’s when I learned what raw pointers are actually for.</p> <h2 id="references-vs-raw-pointers">References vs Raw Pointers</h2> <p>Rust references (<code>&T</code> and <code>&mut T</code>) come with guarantees enforced by the compiler:</p> </article> <article> <h1>Lesson 7: Testing Microservices — Contract tests and integration</h1> <p>Sat, 14 Jun 2025 07:33:00 +0000</p> <p>I deployed a change to the order service that renamed a field from <code>total_amount</code> to <code>total_cents</code>. Made perfect sense — cents avoid floating-point nonsense. All unit tests passed. Integration tests passed. Staging looked fine.</p> <p>Production broke instantly. The payment service was still expecting <code>total_amount</code>. It deserialized the response, got <code>None</code> for the amount, and started processing $0 charges. We caught it in four minutes, but four minutes of free orders adds up.</p> </article> <article> <h1>Lesson 8: Production Error Architecture — Designing the error system for a real service</h1> <p>Sat, 14 Jun 2025 00:00:00 +0000</p> <p>This is the lesson where everything comes together. Over the previous seven lessons we’ve looked at sentinels and typed errors, wrapping strategy, error classification, where to log, how to translate at layer boundaries, and when panic is actually defensible. Now I want to show you what all of that looks like assembled into a complete, production-ready error system for a real API service.</p> <p>I’m going to build the full error architecture for a hypothetical orders API. By the end you’ll have a template you can adapt directly — the error type hierarchy, the middleware, the structured logging, and the client-facing error codes. This is the code I wish I’d had when I started building services in Go.</p> </article> <article> <h1>Lesson 1: What unsafe Actually Means — The contract you're signing</h1> <p>Thu, 12 Jun 2025 08:32:00 +0000</p> <p>I spent my first six months writing Rust thinking <code>unsafe</code> meant “this code is dangerous and you should feel bad.” That misunderstanding cost me weeks — I’d bend over backwards to avoid it, writing convoluted safe wrappers around problems that genuinely needed a raw pointer or two. Once I actually read the Rustonomicon and understood what <code>unsafe</code> <em>really</em> means, everything clicked.</p> <p>Let’s clear this up properly.</p> <h2 id="unsafe-is-not-what-you-think">unsafe Is Not What You Think</h2> <p>Here’s the biggest misconception in the Rust ecosystem: <code>unsafe</code> does not mean “this code is broken” or “this code does bad things.” It means <strong>“I, the programmer, am upholding invariants that the compiler cannot verify.”</strong></p> </article> <article> <h1>Lesson 7: Race Conditions and the Go Memory Model — The bug you can't reproduce</h1> <p>Thu, 12 Jun 2025 00:00:00 +0000</p> <p>Race conditions are the category of bug that makes senior engineers paranoid and junior engineers dismissive. They don’t reproduce consistently. Your tests pass. Your staging environment looks fine. Then, in production, under a specific load pattern at a specific time, two goroutines read and write the same memory address with no synchronization, and you get corrupted data — or a panic — or silently wrong results that sit in your database for three weeks before someone notices. Understanding why they happen at the language level is what separates engineers who prevent them from engineers who just get lucky.</p> </article> <article> <h1>Lesson 6: Distributed Tracing Across Services — Following requests</h1> <p>Wed, 11 Jun 2025 10:45:00 +0000</p> <p>“It’s slow” is the most useless bug report in a microservices world. Slow where? The API gateway? The order service? The database query inside the payment service? The message queue between inventory and shipping? When a single user action touches five services and three databases, “it’s slow” could mean anything.</p> <p>I spent an entire afternoon once trying to track down a latency spike. Added timing logs to every service. Correlated timestamps across hosts. Manually stitched together the request flow from six different log streams. Found the culprit: a DNS resolution that was taking 800ms because of a misconfigured resolver — in a service I didn’t even know was involved.</p> </article> <article> <h1>Lesson 7: go:generate and Code Generation — Let the machine write the boring code</h1> <p>Tue, 10 Jun 2025 00:00:00 +0000</p> <p><code>go:generate</code> is Go’s mechanism for attaching arbitrary code generation commands to your source files. It is not magic — it is a convention that tells <code>go generate</code> which commands to run and where. When you run <code>go generate ./...</code>, the tool reads every <code>//go:generate</code> comment in your source tree and executes the commands they reference. What those commands produce is up to you: <code>String()</code> methods for enum types, serialization code, mock implementations, database query functions, or anything else you can express as a code generator.</p> </article> <article> <h1>Lesson 5: Service Mesh Integration — Istio, Linkerd, and Rust</h1> <p>Mon, 09 Jun 2025 16:21:00 +0000</p> <p>I’ll be honest — when someone first pitched “service mesh” to me, I thought it was over-engineered marketing. You’re telling me I need a sidecar proxy bolted onto every pod, a control plane to manage those proxies, and custom CRDs to configure traffic routing… just to do what a load balancer and some retry logic could handle?</p> <p>Then I ran a fleet of 20+ services in production. mTLS between everything? Doing that in application code is painful. Per-route retry policies? Circuit breaking with consistent configuration? Gradual traffic shifting for canary deploys? At that scale, doing it all in app code means doing it differently in every service, with different bugs in each implementation.</p> </article> <article> <h1>Lesson 4: Saga Pattern — Distributed transactions without 2PC</h1> <p>Sat, 07 Jun 2025 08:48:00 +0000</p> <p>Here’s a scenario that’ll ruin your week. A customer places an order. Your order service saves it. Your payment service charges their card. Your inventory service reserves the items. Your shipping service schedules a pickup. Then the shipping service discovers the item is oversized and can’t be shipped to that address.</p> <p>Now what? The card’s been charged. The inventory’s been reserved. The order exists. You need to undo three things across three services, each with their own database, each with their own failure modes. Welcome to distributed transactions.</p> </article> <article> <h1>Lesson 21: 1D DP Basics — If you can solve it recursively, you can DP it</h1> <p>Fri, 06 Jun 2025 00:00:00 +0000</p> <p>Every time I bombed a DP problem in a mock interview, the pattern was the same: I stared at the problem, thought “this looks like DP,” then froze because I couldn’t immediately write the recurrence. The fix wasn’t to memorize more recurrences. The fix was to stop trying to think bottom-up first.</p> <p>Here’s the approach that finally clicked: write the recursive solution first. Get it working. Then ask: “which subproblems am I solving multiple times?” Memoize those. Then, if you want to be clean about it, flip it into a bottom-up table. By the time you hit the bottom-up version, the recurrence is already obvious because you derived it from your own recursive code.</p> </article> <article> <h1>Lesson 3: Event-Driven Architecture in Rust — Decoupled systems</h1> <p>Thu, 05 Jun 2025 11:02:00 +0000</p> <p>The worst production incident I ever dealt with was a cascading failure triggered by a single slow database query. Service A called Service B synchronously, which called Service C, which ran a query that usually took 2ms but on that particular Tuesday took 45 seconds because of a missing index on a new column. Service A’s thread pool exhausted, its health check failed, Kubernetes restarted it, and for twenty minutes the entire checkout flow was down — because of a read query in a recommendation engine.</p> </article> <article> <h1>Lesson 8: Packaging and Distributing — GoReleaser, Homebrew, and getting your tool to users</h1> <p>Thu, 05 Jun 2025 00:00:00 +0000</p> <p>Building a great CLI tool is half the job. The other half is getting it to users without making them compile it from source, navigate a GitHub releases page manually, or run a curl-pipe-to-bash script from an unverified URL. Distribution is where many Go projects stop short: the binary exists, the README says <code>go install</code>, and that is considered “distributed.”</p> <p><code>go install</code> is fine for Go developers. It is not acceptable for operators, system administrators, and end users who reasonably expect <code>brew install</code> or <code>apt install</code>. GoReleaser closes this gap by automating the full release pipeline — cross-compiled binaries, checksums, GitHub releases, Homebrew formulas, Debian packages, Docker images — from a single configuration file and one <code>git push --tags</code>.</p> </article> <article> <h1>Lesson 10: Distributed System Patterns — Consensus, CRDTs, and consistency</h1> <p>Wed, 04 Jun 2025 11:08:00 +0000</p> <p>I once watched a team spend six months building a “distributed database” that was really just PostgreSQL with a cron job that copied rows between data centers. It worked until it didn’t — conflicting writes, lost updates, and an incident where the same order was fulfilled twice from different warehouses. They learned the hard way that distributed systems aren’t just “run it on multiple machines.” They’re a fundamentally different programming model with different guarantees, different failure modes, and different mental models.</p> </article> <article> <h1>Lesson 2: gRPC Microservices with tonic — Production-grade RPC</h1> <p>Tue, 03 Jun 2025 14:37:00 +0000</p> <p>The first time I used gRPC in production was on a Go project. The experience was fine — <code>protoc</code> generated stubs, you implemented an interface, done. Then I tried <code>tonic</code> in Rust, and I realized what gRPC was <em>supposed</em> to feel like. Type-safe request/response types generated at compile time, streaming that works with Rust’s async model, and interceptors built on the same Tower middleware stack as Axum. It’s gRPC done right.</p> </article> <article> <h1>Lesson 21: Composition Over Inheritance — Small pieces, loosely joined</h1> <p>Mon, 02 Jun 2025 00:00:00 +0000</p> <p>If you’ve come from Java or C++, you’re probably waiting for Go to show you its inheritance model. Where’s the <code>extends</code> keyword? Where are the base classes? There aren’t any — Go made a deliberate choice to leave them out. After writing a few thousand lines of Go, most people agree it was the right call.</p> <h2 id="the-problem">The Problem</h2> <p>Object-oriented languages lean heavily on the “is-a” relationship. A <code>Dog</code> is-a <code>Animal</code>. A <code>Manager</code> is-a <code>Employee</code>. This sounds elegant until real-world complexity enters the picture: is a <code>FlyingFish</code> a <code>Fish</code> or a <code>Bird</code>? Now you’re in multiple inheritance territory and things get messy fast. And in Go, the instinct to fake it with named fields creates its own noise:</p> </article> <article> <h1>Lesson 9: Message Queues — NATS, Kafka, RabbitMQ from Rust</h1> <p>Sun, 01 Jun 2025 15:25:00 +0000</p> <p>The moment I stopped thinking of services as calling each other and started thinking of them as reacting to events, my architecture got dramatically simpler. Instead of service A calling service B calling service C in a synchronous chain that’s as fragile as it sounds, service A publishes an event. Services B and C subscribe and react independently. A doesn’t even know they exist. B can be down for maintenance without affecting A. C can be added next month without changing A’s code. Message queues are the backbone of this pattern.</p> </article> <article> <h1>Lesson 1: Service Boundaries and API Contracts — Where to draw the lines</h1> <p>Sun, 01 Jun 2025 09:14:00 +0000</p> <p>I once joined a team that had 47 microservices for what was essentially a CRUD app with a payment flow. Forty-seven. Each one had its own database, its own deployment pipeline, its own on-call rotation. When a customer placed an order, the request bounced through eleven services before a confirmation email went out. Latency was terrible, debugging was a nightmare, and nobody could explain why the “UserPreferences” service existed separately from the “UserProfile” service.</p> </article> <article> <h1>Lesson 8: Linting with golangci-lint — Automate what reviewers shouldn''t waste time on</h1> <p>Sun, 01 Jun 2025 00:00:00 +0000</p> <p>I made a rule for myself a few years ago: if I leave a code review comment about something a tool could have caught, I’ve wasted both the author’s time and mine. A linter can catch unused variables, missing error checks, shadowed variables, inefficient string concatenation, and dozens of other patterns automatically — in seconds, every commit, without reviewer fatigue. The code review should be about design and correctness, not about whether someone forgot to handle an error returned by <code>rows.Close()</code>.</p> </article> <article> <h1>Lesson 6: Mutexes Done Right — The boring tool that actually works</h1> <p>Sat, 31 May 2025 00:00:00 +0000</p> <p>Channels get the spotlight in Go talks and blog posts — they’re the shiny, idiomatic, philosophically interesting tool. Mutexes feel like the C and Java baggage everyone was supposed to leave behind. But here’s what I’ve learned after several years of writing concurrent Go: mutexes are often the <em>right</em> tool, especially when you’re protecting shared state, and the problems you see in production are almost never “we should’ve used channels” — they’re “we copied the mutex” or “we forgot to narrow the critical section.” Learn to use mutexes properly and stop apologizing for them.</p> </article> <article> <h1>Lesson 8: Circuit Breakers in Rust — Failing fast</h1> <p>Thu, 29 May 2025 07:35:00 +0000</p> <p>Picture this: your payment service depends on a fraud detection API that’s completely down. Every request to it takes 30 seconds to timeout. Your payment service has 200 requests queued up, each holding a thread and a database connection while waiting for fraud detection to respond. Within minutes, you’re out of connections, the payment service itself starts failing, and now the checkout service that depends on payments starts failing too. One dead service has cascaded into a full outage.</p> </article> <article> <h1>Lesson 7: Retry Strategies and Exponential Backoff — Resilient clients</h1> <p>Mon, 26 May 2025 10:40:00 +0000</p> <p>Here’s a scenario that’s burned me more than once: a downstream service has a brief hiccup — maybe a pod is restarting, maybe there’s a momentary network partition — and instead of gracefully retrying, my service immediately returns a 500 to every caller. The hiccup lasts 3 seconds. My P99 latency graph spikes. On-call gets paged. Everyone’s unhappy. The fix? A retry loop with exponential backoff. Three lines of logic that would’ve made the entire incident invisible.</p> </article> <article> <h1>Lesson 6: TLS — rustls and native TLS</h1> <p>Fri, 23 May 2025 19:10:00 +0000</p> <p>I’ll never forget the 3am page that turned out to be an expired TLS certificate. Our automated renewal had been silently failing for two weeks, nobody noticed because the cert was still valid, and then at 2:47am on a Sunday it expired and every client started getting connection errors. We had monitoring for CPU, memory, disk, latency, error rates — but not for certificate expiry. That was the day I decided to actually understand TLS instead of just copy-pasting cert paths into config files.</p> </article> <article> <h1>Lesson 7: context Internals — How cancellation propagates under the hood</h1> <p>Thu, 22 May 2025 00:00:00 +0000</p> <p><code>context.Context</code> is the most important type in Go’s standard library that most people use by convention without fully understanding. You pass it as the first argument to functions. You check <code>ctx.Done()</code> in goroutines. You create derived contexts with <code>context.WithTimeout</code>. It works — until it doesn’t, and you have a goroutine that doesn’t cancel when the parent context does, or a context that leaks forever because you forgot to call the cancel function.</p> </article> <article> <h1>Lesson 5: DNS Resolution and Custom Resolvers — Understanding name resolution</h1> <p>Wed, 21 May 2025 13:55:00 +0000</p> <p>A few months back, our entire staging environment went down for an hour. Not because any service crashed — because someone changed a DNS record and forgot that our Kubernetes ingress had a 5-minute TTL cache while the CDN had a 24-hour cache. Half our traffic was going to the old IP, half to the new one. Debugging it took forever because <code>dig</code> on my laptop showed the correct answer, but the services inside the cluster were seeing stale records.</p> </article> <article> <h1>Lesson 5: sync.WaitGroup — Wait for everyone, then move on</h1> <p>Wed, 21 May 2025 00:00:00 +0000</p> <p><code>sync.WaitGroup</code> is one of the first concurrency primitives you reach for in Go, and also one of the first you misuse. The API looks deceptively simple — three methods, twenty minutes of reading, you think you’ve got it. Then you hit a negative counter panic in production, or you find out your <code>Wait()</code> returned while goroutines were still running, and you spend an afternoon learning the rules you thought you already knew.</p> </article> <article> <h1>Lesson 9: Fake Clean Architecture — Layers without purpose are just folders</h1> <p>Tue, 20 May 2025 00:00:00 +0000</p> <p>I cloned a Go repository that was described to me as a “clean architecture” implementation. It had six layers: <code>handler</code>, <code>usecase</code>, <code>service</code>, <code>repository</code>, <code>model</code>, and <code>dto</code>. Every user-related operation required touching at least four files across four packages. When I added a new field to the user profile, I updated the database schema, the <code>model.User</code>, the <code>dto.UserDTO</code>, the <code>repository.UserRepository</code>, the <code>service.UserService</code>, the <code>usecase.UserUseCase</code>, and the <code>handler.UserHandler</code>. Eight files for one field. The indirection was total, the business logic was nowhere — it was scattered across the layers in thin delegating functions that called the layer below and returned the result.</p> </article> <article> <h1>Lesson 4: The comma ok Idiom — Two returns that save you from panics</h1> <p>Mon, 19 May 2025 00:00:00 +0000</p> <p>There are three places in Go where a missing second return value means your program either silently does the wrong thing or blows up entirely: reading from a map with a missing key, asserting a type on an interface, and receiving from a closed channel. The language’s answer to all three is the same — a boolean second return that tells you whether the operation actually succeeded. This is the comma-ok idiom, and you’ll use it constantly.</p> </article> <article> <h1>Lesson 8: Security Fuzzing — Finding vulnerabilities before attackers do</h1> <p>Sun, 18 May 2025 13:29:00 +0000</p> <p>I found a panic in a production parser by accident last year. A user in Japan sent a request with a multi-byte UTF-8 character right at a boundary where our code was slicing a string by byte index. It worked fine for ASCII. It worked fine for most Unicode. But this particular combination of character and position triggered an index-out-of-bounds panic that crashed the request handler.</p> <p>I fixed the bug in ten minutes. What bothered me was that we’d had unit tests, integration tests, and even some property-based tests — and none of them caught it. The input space was too large. The edge case was too specific. A human writing test cases would never think to put a 3-byte UTF-8 character at exactly that offset.</p> </article> <article> <h1>Lesson 4: WebSocket Servers and Clients — Real-time communication</h1> <p>Sun, 18 May 2025 08:20:00 +0000</p> <p>I built my first WebSocket server to power a live dashboard that showed deployment status across our fleet. The alternative was polling every 2 seconds — 500 browser tabs hitting the API, each getting back the same “nothing changed” response 99% of the time. WebSockets turned that from 250 requests/second of wasted work into a handful of persistent connections that only sent data when something actually happened.</p> <h2 id="http-vs-websockets--when-do-you-need-them">HTTP vs WebSockets — When Do You Need Them?</h2> <p>HTTP is request-response. Client asks, server answers. Great for most things. But some use cases fundamentally don’t fit that model:</p> </article> <article> <h1>Lesson 5: Embedding and Vector Search — Semantic search in Go without Python</h1> <p>Sun, 18 May 2025 00:00:00 +0000</p> <p>For a long time, embedding-based semantic search felt like Python territory. The tutorials all pointed to LangChain, FAISS, and numpy. But the actual operations — generate an embedding vector, store it in a database, query for nearest neighbors — map directly onto Go’s strengths: clean HTTP client code for the embedding API, <code>pgx</code> for PostgreSQL with pgvector, and fast concurrent query pipelines. I’ve built production semantic search systems entirely in Go and they’re fast, maintainable, and don’t require a Python sidecar.</p> </article> <article> <h1>Interview Patterns L20: Shortest Path — When edges have weights</h1> <p>Sat, 17 May 2025 00:00:00 +0000</p> <p>In L16, I explained why BFS solves shortest path problems in unweighted graphs — every edge costs the same, so distance equals hop count, and BFS naturally explores in order of increasing hops. But the moment edges have different weights, BFS breaks. A path with two heavy edges can be longer than a path with ten light ones.</p> <p>This is the lesson where we graduate to weighted shortest path. Two algorithms matter most for interviews: Dijkstra’s (greedy, non-negative weights) and Bellman-Ford (dynamic programming, handles negative weights). A third problem shows a modified Dijkstra on a 2D grid. Understanding when to use each — and why the other would be wrong — is what separates candidates who have memorized code from candidates who actually understand the algorithms.</p> </article> <article> <h1>Lesson 3: gRPC with tonic — High-performance RPC</h1> <p>Fri, 16 May 2025 11:30:00 +0000</p> <p>The first time I used gRPC in production, I was skeptical. We already had REST APIs that worked fine — why add protobuf compilation, code generation, and an entirely new protocol? Then our team grew to four services in three languages, and the answer became painfully obvious. Every REST endpoint had slightly different JSON field naming, different error formats, and documentation that was always a version behind. gRPC eliminated all of that overnight.</p> </article> <article> <h1>Lesson 7: Sandboxing and Privilege Dropping — Least privilege</h1> <p>Thu, 15 May 2025 07:41:00 +0000</p> <p>Here’s a pattern I’ve seen too many times: a Rust web service runs as root in a Docker container because “it needs to bind port 443.” The service handles user uploads, parses JSON, processes images, and talks to a database — all with root privileges. If any part of that pipeline has a vulnerability, the attacker gets root on the container. And if the container isn’t properly isolated, they might get the host too.</p> </article> <article> <h1>Lesson 8: gRPC Basics and Streaming — Protobuf on the wire, types in your code</h1> <p>Thu, 15 May 2025 00:00:00 +0000</p> <p>My team migrated a set of internal service APIs from JSON over HTTP/1.1 to gRPC roughly two years ago. The motivating factors were type safety across service boundaries, binary serialization that was 5-10x smaller on the wire, and bidirectional streaming that HTTP/1.1 can’t do at all. The migration took about a week per service and the performance improvements were immediately visible in our latency percentiles.</p> <p>gRPC is a Remote Procedure Call framework that runs over HTTP/2. The interface is defined in Protocol Buffers — a language-neutral schema language — and the gRPC toolchain generates client and server stubs in Go. You call a method; the framework handles serialization, connection management, and streaming.</p> </article> <article> <h1>Lesson 2: HTTP Clients — reqwest and hyper</h1> <p>Wed, 14 May 2025 16:45:00 +0000</p> <p>I once spent three hours debugging a production issue that turned out to be an HTTP client with no timeout configured. Three hours. The client was happily waiting forever for a response from a service that had crashed, holding a database connection open the entire time. That experience permanently changed how I think about HTTP clients — they’re not just “make a request, get a response.” They’re complex state machines with connection pools, redirect policies, timeout hierarchies, and a dozen other knobs that matter when things go wrong.</p> </article> <article> <h1>Lesson 7: Panic, Recover, and When They're Actually Justified — Panic is not error handling</h1> <p>Tue, 13 May 2025 00:00:00 +0000</p> <p>I’ve seen <code>panic(err)</code> used as error handling more times than I’d like to admit — including in codebases I helped build. The reasoning always sounds logical at the time: “this error should never happen, and if it does, the program state is corrupt anyway, so why not just panic?” The problem is that “should never happen” is a statement about your expectations, not about reality. And “program state is corrupt” is almost never true — one request failed, the other thousand are still fine.</p> </article> <article> <h1>Lesson 6: Supply Chain Security — Lockfiles, vendoring, and trust</h1> <p>Mon, 12 May 2025 10:08:00 +0000</p> <p>The xz backdoor was a wake-up call for the entire industry, but honestly, supply chain attacks had been happening for years before that — just more quietly. Typosquatting on npm, malicious PyPI packages, compromised maintainer accounts. The question isn’t whether Rust’s ecosystem is vulnerable to supply chain attacks. It is. The question is what you’re doing about it.</p> <p>I spent a week last year hardening our build pipeline after we realized that a <code>cargo build</code> on our CI server was pulling fresh crate downloads from the internet with no verification beyond what Cargo does by default. If crates.io got compromised, or if our DNS got hijacked, we’d be compiling and shipping attacker code with zero friction.</p> </article> <article> <h1>Lesson 1: Building a TCP Server from Scratch — Raw sockets</h1> <p>Mon, 12 May 2025 09:14:00 +0000</p> <p>Last month I was debugging a flaky microservice at work and realized I couldn’t explain what was actually happening between <code>bind()</code> and the first byte arriving. I’d been using high-level frameworks for years — Actix, Axum, you name it — but I’d never actually built a TCP server from raw sockets in Rust. That bothered me. So I spent a weekend doing exactly that, and honestly, it changed how I think about every networked service I write.</p> </article> <article> <h1>Lesson 4: Buffered vs Unbuffered Channels — Buffering hides bugs</h1> <p>Mon, 12 May 2025 00:00:00 +0000</p> <p>The first time someone tells you that buffered channels are faster, you believe them — and you spend the next year throwing <code>make(chan T, 100)</code> at every performance complaint, wondering why your system still deadlocks sometimes, and why those deadlocks disappeared when you bumped the buffer to 200. The buffer wasn’t fixing anything. It was delaying the problem. Understanding why requires actually thinking about what buffering changes — not at the performance level, but at the coordination level.</p> </article> <article> <h1>Lesson 9: Config Management — Twelve-factor or twelve headaches</h1> <p>Sat, 10 May 2025 00:00:00 +0000</p> <p>I have seen configuration managed in at least ten different ways across the Go projects I have worked on: hardcoded constants, config structs passed around by pointer, global variables read at startup, YAML files baked into Docker images, environment variables with no validation, and one particularly creative approach involving a shared Google Sheet. Every one of those had the same core problem: the configuration was not treated as a first-class part of the application.</p> </article> <article> <h1>Lesson 5: Dependency Auditing — cargo-audit and cargo-deny</h1> <p>Fri, 09 May 2025 14:55:00 +0000</p> <p>You know what keeps me up at night? Not my own code — I can review that. It’s the 200+ transitive dependencies in my <code>Cargo.lock</code> that I’ve never read a single line of. Every one of those crates runs with the same permissions as my code. If any of them has a vulnerability, it’s my vulnerability.</p> <p>This isn’t theoretical. In 2024, the <code>xz</code> backdoor showed that even core infrastructure maintained by a single person can be compromised. Rust’s ecosystem isn’t immune. We’ve had actual advisories for real crates — buffer overflows in parsing libraries, unsound <code>unsafe</code> code in popular crates, logic bugs in crypto implementations.</p> </article> <article> <h1>Lesson 8: Release Profiles and Build Optimization — Shipping fast binaries</h1> <p>Thu, 08 May 2025 13:50:00 +0000</p> <p>I was benchmarking two builds of the same service — one with default release settings, one with a tuned profile. Same code. Same hardware. The tuned build was 22% faster on our hot path and 40% smaller. I didn’t change a single line of Rust. Just <code>Cargo.toml</code> settings.</p> <p>Most Rust developers know about <code>cargo build --release</code>. Fewer know that <code>--release</code> is just a starting point — there’s a whole set of knobs in the release profile that trade compile time for runtime performance, or binary size, or debuggability. Let me walk you through every one that matters.</p> </article> <article> <h1>Lesson 8: Designing Interfaces for Libraries — Libraries export interfaces, apps consume them</h1> <p>Thu, 08 May 2025 00:00:00 +0000</p> <p>Writing a library for other Go developers is a fundamentally different design problem than writing application code. In an application, you control every call site. If an interface needs to change, you update all the callers. In a library, your callers are other people, other teams, other binaries you have never seen — and when you change a public interface, you break them all in ways you cannot fix yourself. This constraint forces a discipline that makes library-authored Go interfaces among the most carefully designed in the ecosystem.</p> </article> <article> <h1>Lesson 4: Secret Management — zeroize and secure memory</h1> <p>Wed, 07 May 2025 08:23:00 +0000</p> <p>A while back I was debugging a crash in production and pulled a core dump from the server. Sitting right there in the heap, in plain text, was a database connection string with credentials. The service had loaded the secret from Vault on startup, stored it in a regular <code>String</code>, and that <code>String</code> stayed in memory for the entire process lifetime. When it crashed, the secret got written to disk in the core dump.</p> </article> <article> <h1>Lesson 3: Cryptography — ring, RustCrypto, and sodiumoxide</h1> <p>Mon, 05 May 2025 11:47:00 +0000</p> <p>I’m going to say something controversial: most developers should never write cryptographic code. Not because they’re not smart enough — because the field is absurdly hostile to even tiny mistakes. A single branch in your constant-time comparison function leaks timing information. A reused nonce in AES-GCM completely destroys confidentiality. An ECDSA implementation with a biased random number generator leaks your private key after enough signatures.</p> <p>But you still need to <em>use</em> cryptography. Every production system needs hashing, encryption, signatures, or key derivation at some point. The trick is picking the right library, using it correctly, and understanding just enough of the theory to avoid the common footguns.</p> </article> <article> <h1>Lesson 7: Configuration — Environment, files, feature flags</h1> <p>Mon, 05 May 2025 10:15:00 +0000</p> <p>I once shipped a service to production with the staging database URL hardcoded. Not in an environment variable — literally in the source code, in a <code>const</code>. It ran for two hours writing production data to the staging database before anyone noticed. The fix was easy. The data migration to clean up the mess took three days.</p> <p>Configuration is one of those things that seems trivial until it bites you. And in Rust, we have the type system to make configuration bulletproof — but only if we structure things right. Let me walk you through the approach I’ve converged on after making every possible configuration mistake.</p> </article> <article> <h1>Lesson 16: Channels Are for Coordination — Stop using channels as fancy mutexes</h1> <p>Mon, 05 May 2025 00:00:00 +0000</p> <p>Channels are Go’s most recognizable concurrency feature, and also one of the most misused. The moment engineers learn about them, there’s a strong temptation to reach for a channel every time two goroutines need to interact. That instinct is wrong about half the time. Channels are for coordination — signaling events, distributing work, collecting results. They are not a universal replacement for shared state.</p> <p>Rob Pike’s line from his 2012 talk sums it up: “Do not communicate by sharing memory; share memory by communicating.” That’s a guiding philosophy, not an absolute rule.</p> </article> <article> <h1>Lesson 9: Dependency Scanning — govulncheck before you deploy</h1> <p>Mon, 05 May 2025 00:00:00 +0000</p> <p>The security posture of your Go application is not just about the code you write — it is also about the code you import. A typical Go microservice will have dozens of direct and transitive dependencies. Any one of them might have a known vulnerability in the specific version you are using. Unlike the bugs in your own code, these vulnerabilities are publicly catalogued, exploits are often published, and attackers scan for them at scale.</p> </article> <article> <h1>Lesson 2: Input Validation and Sanitization — Trust nothing</h1> <p>Sat, 03 May 2025 16:12:00 +0000</p> <p>A few months ago, I was reviewing a PR where someone had written a REST API handler that took a user-supplied filename, appended it to a base path, and opened the file. The code compiled perfectly. Clippy was happy. Tests passed. And it was a textbook path traversal vulnerability — <code>../../etc/passwd</code> would work just fine.</p> <p>Rust’s type system protects you from memory corruption. It doesn’t protect you from trusting user input. That’s still on you. And honestly? It’s where most production vulnerabilities in Rust code are going to come from.</p> </article> <article> <h1>Lesson 6: Graceful Shutdown — Draining connections cleanly</h1> <p>Fri, 02 May 2025 19:45:00 +0000</p> <p>I deployed a new version of a payment service once, and for about 3 seconds during the rollout, a handful of transactions just… vanished. They weren’t in the database. They weren’t in the error logs. The old pods received the requests, started processing them, and then Kubernetes killed the pods before they finished. SIGKILL doesn’t ask nicely — it just terminates the process. Those transactions were gone.</p> <p>Graceful shutdown is the solution. When your service receives SIGTERM (Kubernetes’s way of saying “please stop”), it should stop accepting new requests, finish processing in-flight requests, flush any buffered data, close connections cleanly, and <em>then</em> exit. Get this right and you get zero-downtime deployments. Get it wrong and you get data loss.</p> </article> <article> <h1>Lesson 1: Memory Safety — What Rust gives you for free</h1> <p>Thu, 01 May 2025 09:34:00 +0000</p> <p>Last year I inherited a C++ service that had been “battle-tested” in production for three years. Within a week of digging through crash dumps, I found two use-after-free bugs, a buffer overread that leaked heap data into API responses, and a data race in the connection pool that only triggered under load. Three years. Battle-tested. Right.</p> <p>That experience is what finally pushed me from “Rust is interesting” to “Rust is non-negotiable for anything touching the network.” The memory safety guarantees aren’t just a nice-to-have — they’re the single biggest security win you get by choosing Rust.</p> </article> <article> <h1>Lesson 5: Health Checks and Readiness Probes — Production liveness</h1> <p>Wed, 30 Apr 2025 14:05:00 +0000</p> <p>A service I maintained once passed all its health checks while silently dropping 30% of incoming requests. The health endpoint returned 200 OK every time Kubernetes asked. The database connection pool was exhausted, the service couldn’t process anything, but that little <code>/health</code> endpoint — which didn’t touch the database — happily reported everything was fine.</p> <p>That’s when I learned the difference between a health check that checks health and one that just says “the process is running.” They’re very different things, and getting this wrong means your orchestrator keeps sending traffic to a broken instance instead of replacing it.</p> </article> <article> <h1>Interview Patterns L19: Union Find — Who belongs to whom?</h1> <p>Wed, 30 Apr 2025 00:00:00 +0000</p> <p>Union Find is one of those data structures that most people never implement until they need it in an interview, and then they discover it is both elegant and surprisingly short. The core idea is deceptively simple: maintain a “parent” array where each element points to its group’s representative. Two operations — <code>Find</code> (who is the root of this group?) and <code>Union</code> (merge two groups) — are all you need.</p> </article> <article> <h1>Lesson 4: Observability — tracing, metrics, OpenTelemetry</h1> <p>Sun, 27 Apr 2025 08:22:00 +0000</p> <p>I once spent six hours debugging a production issue where requests were randomly timing out. No errors in the logs. CPU and memory looked fine. Response times were normal — except for the 2% that took 30 seconds. Without distributed tracing, I was blind. I ended up bisecting the problem by adding <code>println!</code> statements, deploying them one at a time, and watching CloudWatch. It was miserable.</p> <p>That experience permanently changed how I build services. Observability isn’t something you bolt on when things break. It’s something you build in from day one, or you pay for it later — with your time, your sleep, and your sanity.</p> </article> <article> <h1>Lesson 3: Channel Ownership Rules — Who closes the channel?</h1> <p>Fri, 25 Apr 2025 00:00:00 +0000</p> <p>At some point, you’re going to close a channel twice and the runtime is going to panic with <code>close of closed channel</code>. Or you’re going to close a channel from the wrong goroutine and send a value into it right after, and the runtime is going to panic with <code>send on closed channel</code>. These aren’t subtle race conditions that only show up under load — they’re logic errors that exist because nobody in the codebase agreed on who <em>owns</em> the channel. That agreement is the whole game.</p> </article> <article> <h1>Lesson 3: CI/CD for Rust — GitHub Actions, caching, cargo-nextest</h1> <p>Thu, 24 Apr 2025 11:30:00 +0000</p> <p>My first Rust CI pipeline took 45 minutes. Forty-five. Every push triggered a full dependency build, tests ran sequentially, and clippy ran as a separate job that also built everything from scratch. I was burning through GitHub Actions minutes like they were free — which they are for open source, but my patience certainly wasn’t.</p> <p>Getting Rust CI right is mostly about caching. The compilation model means a clean build downloads and compiles hundreds of crates, and without caching, every single CI run pays that cost. Let me show you the pipeline I’ve landed on after iterating through dozens of projects.</p> </article> <article> <h1>Lesson 10: Using unsafe to Escape the Borrow Checker — The wrong reason</h1> <p>Thu, 24 Apr 2025 09:30:00 +0000</p> <p>I found this in a production codebase:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">get_or_insert</span>(<span style="color:#f92672">&</span><span style="color:#66d9ef">mut</span> self, key: <span style="color:#66d9ef">&</span><span style="color:#66d9ef">str</span>) -> <span style="color:#66d9ef">&</span><span style="color:#a6e22e">mut</span> Value { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">if</span> <span style="color:#f92672">!</span>self.map.contains_key(key) { </span></span><span style="display:flex;"><span> self.map.insert(key.to_string(), Value::default()); </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> <span style="color:#75715e">// "The borrow checker is being stupid, we know the key exists" </span></span></span><span style="display:flex;"><span> <span style="color:#66d9ef">unsafe</span> { <span style="color:#f92672">&</span><span style="color:#66d9ef">mut</span> <span style="color:#f92672">*</span>(self.map.get_mut(key).unwrap() <span style="color:#66d9ef">as</span> <span style="color:#f92672">*</span><span style="color:#66d9ef">mut</span> Value) } </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>The comment says it all. The developer hit a borrow checker error — a legitimate one about borrowing <code>self.map</code> mutably twice — and instead of restructuring the code, they cast through a raw pointer to silence the compiler. This is undefined behavior. The compiler is allowed to assume the mutable references don’t alias, and it <em>will</em> optimize based on that assumption. When it does, your program does something you didn’t write.</p> </article> <article> <h1>Lesson 2: Static Linking with musl — Single binary deploys</h1> <p>Tue, 22 Apr 2025 16:40:00 +0000</p> <p>Last year I had to deploy a Rust service to a hardened environment — no package manager, no shared libraries, no internet access. Just a bare Linux kernel and my binary. If my binary depended on libc, libssl, or anything else in <code>/usr/lib</code>, it simply wouldn’t start. That constraint forced me to learn static linking properly, and it turned out to be one of the best deployment patterns I’ve ever used.</p> </article> <article> <h1>Lesson 9: Macro Abuse — When a function would do</h1> <p>Mon, 21 Apr 2025 17:08:00 +0000</p> <p>I spent an entire afternoon debugging a test failure that turned out to be caused by a macro expanding variable names in a way I didn’t expect. The macro was called <code>make_handler!</code> and it generated HTTP handler functions from a declarative DSL that someone on the team had invented. The “DSL” saved maybe ten lines of boilerplate per handler. The macro definition was 200 lines of nested <code>macro_rules!</code> with five recursion levels, three <code>tt</code> munchers, and hygiene workarounds that I’m still not convinced were correct. When a new developer asked how to add a query parameter to a handler, nobody could explain it without first teaching them how the macro worked.</p> </article> <article> <h1>Lesson 8: Capacity Matters — The allocation tax you''re paying without knowing</h1> <p>Mon, 21 Apr 2025 00:00:00 +0000</p> <p>There’s a one-line fix that will make your hot paths faster, use less memory, and reduce GC pressure. It costs you nothing in readability. Most Go programmers know about it. Far fewer actually do it consistently. The fix is telling Go how big a slice is going to be before you start filling it.</p> <h2 id="the-problem">The Problem</h2> <p>This is the pattern you reach for by reflex, especially if you’ve come from languages where dynamic arrays just grow as needed:</p> </article> <article> <h1>Lesson 1: Docker for Rust — Multi-stage builds, minimal images</h1> <p>Sun, 20 Apr 2025 09:15:00 +0000</p> <p>The first time I shipped a Rust service in Docker, my image was 2.1 GB. Two. Point. One. Gigabytes. For a binary that was 8 MB. I’d used <code>rust:latest</code> as my base, ran <code>cargo build --release</code> inside it, and called it a day. The image had GCC, LLVM, every system library known to humanity, and my tiny HTTP server somewhere in the corner.</p> <p>That was the day I learned about multi-stage builds. And honestly, getting Docker right for Rust is one of those things that separates “I deployed it” from “I deployed it well.”</p> </article> <article> <h1>Lesson 8: Premature Optimization — Profile before you optimize</h1> <p>Sat, 19 Apr 2025 13:42:00 +0000</p> <p>A teammate once spent three days replacing every <code>String</code> in our data model with a custom arena-allocated string type. The rationale: “String allocations are slow, and we’re processing a lot of data.” Sounds reasonable, right? After the rewrite, I ran the benchmarks. The improvement was within noise — less than 1%. The actual bottleneck was network I/O to an external API, which accounted for 94% of the request latency. Those three days of intricate unsafe string manipulation? Completely wasted. And the code was now harder to read, harder to maintain, and had a subtle use-after-free bug that we found six weeks later.</p> </article> <article> <h1>Lesson 6: Error Boundaries Across Layers — Translate at the border, don't leak internals</h1> <p>Sat, 19 Apr 2025 00:00:00 +0000</p> <p>One of the most subtle security issues I’ve encountered in Go APIs isn’t an authentication bug or a missing authorization check — it’s a SQL error message showing up in a JSON response. Something like <code>{"error": "pq: duplicate key value violates unique constraint \"users_email_key\""}</code>. The frontend is now showing your users your database schema. Not great.</p> <p>This happens because somewhere between the repository and the HTTP response, someone got lazy with error translation. The raw database error bubbled all the way up and got written directly into the response. Error boundaries exist to prevent exactly this — they’re the translation points between layers, where internal implementation details get converted to appropriate external representations.</p> </article> <article> <h1>Lesson 5: Saga Pattern — Distributed transactions without two-phase commit</h1> <p>Fri, 18 Apr 2025 00:00:00 +0000</p> <p>Two-phase commit is theoretically elegant and operationally painful. I’ve seen it cause system-wide deadlocks during network partitions, coordinator failures that required manual database recovery, and deployment coupling so tight that every service had to be upgraded in lockstep. The saga pattern is the alternative — it trades atomicity for availability, compensates for failures with explicit rollback actions, and keeps each service’s transactions entirely local. It’s the pattern I reach for whenever I need “all of this must succeed together” across more than one database.</p> </article> <article> <h1>Lesson 7: Arc<Mutex<T>> as Default — Reach for channels first</h1> <p>Wed, 16 Apr 2025 20:15:00 +0000</p> <p>There’s a specific moment in every Rust developer’s journey where they discover <code>Arc<Mutex<T>></code> and start putting everything in it. I’ve been that developer. I had a web service that needed to share a cache between request handlers, and my first instinct was <code>Arc<Mutex<HashMap<String, CachedItem>>></code>. It worked. Then traffic went up, contention went up, tail latency went up, and I spent a weekend profiling lock contention that shouldn’t have existed in the first place — because most of my “shared mutable state” could have been restructured as message passing.</p> </article> <article> <h1>Lesson 6: Trait Bloat — Interface segregation in Rust</h1> <p>Tue, 15 Apr 2025 09:55:00 +0000</p> <p>I worked on a project that had a <code>Storage</code> trait with twenty-three methods. Twenty-three. It handled reading, writing, deleting, listing, searching, watching for changes, managing permissions, computing checksums, and streaming large files. Every backend — S3, local filesystem, in-memory for tests — had to implement all twenty-three methods. The in-memory test backend had fourteen methods that just returned <code>unimplemented!()</code>. The local filesystem backend panicked on the permissions methods because POSIX permissions don’t map to the trait’s model. And every time someone added a new method to the trait, every backend had to be updated — even the ones where the new method made no sense.</p> </article> <article> <h1>Lesson 8: String Internals — Immutable, backed by bytes, cheaper than you think</h1> <p>Tue, 15 Apr 2025 00:00:00 +0000</p> <p>I used to reach for <code>[]byte</code> over <code>string</code> in performance-sensitive code, assuming strings were somehow more expensive because “immutability must cost something.” That intuition was wrong. Understanding what a string actually is — a read-only slice header — corrected my assumptions and simplified a lot of code I had unnecessarily complicated.</p> <h2 id="the-problem">The Problem</h2> <p>Strings in Go are everywhere, and most developers use them without thinking about what they are at the memory level. This leads to a few common mistakes:</p> </article> <article> <h1>Interview Patterns L18: Topological Sort — Order tasks with dependencies</h1> <p>Mon, 14 Apr 2025 00:00:00 +0000</p> <p>Topological sort comes up whenever there is an ordering constraint — “A must happen before B,” “module X depends on module Y,” “this course is a prerequisite for that one.” The algorithm answers: given a directed acyclic graph (DAG) of dependencies, produce a linear ordering of all nodes such that every node appears after all its predecessors.</p> <p>The word “topological” makes it sound academic. In practice, it is one of the most industrially relevant algorithms: build systems, package managers, spreadsheet recalculation engines, compiler dependency resolution, task schedulers — they all use topological sort or something equivalent. Interviewers ask it because it tests whether you can model real-world dependency problems as graphs and then solve them correctly.</p> </article> <article> <h1>Lesson 5: Over-Genericizing — Not everything needs <T></h1> <p>Sun, 13 Apr 2025 11:28:00 +0000</p> <p>I reviewed a library last year where the author had made literally everything generic. The HTTP client was generic over the transport, the serializer, the deserializer, the error type, the retry policy, the timeout strategy, and the logger. Using it required spelling out a type signature that looked like this:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">let</span> client: <span style="color:#a6e22e">HttpClient</span><span style="color:#f92672"><</span> </span></span><span style="display:flex;"><span> TcpTransport<span style="color:#f92672"><</span>TlsConfig<span style="color:#f92672">></span>, </span></span><span style="display:flex;"><span> JsonSerializer<span style="color:#f92672"><</span>PrettyPrint<span style="color:#f92672">></span>, </span></span><span style="display:flex;"><span> JsonDeserializer<span style="color:#f92672"><</span>StrictMode<span style="color:#f92672">></span>, </span></span><span style="display:flex;"><span> AppError, </span></span><span style="display:flex;"><span> ExponentialBackoff<span style="color:#f92672"><</span>SystemClock<span style="color:#f92672">></span>, </span></span><span style="display:flex;"><span> FixedTimeout, </span></span><span style="display:flex;"><span> SlogLogger<span style="color:#f92672"><</span>JsonFormat<span style="color:#f92672">></span>, </span></span><span style="display:flex;"><span><span style="color:#f92672">></span> <span style="color:#f92672">=</span> HttpClient::new(<span style="color:#75715e">/* ... */</span>); </span></span></code></pre></div><p>The kicker? The library was an internal tool used by exactly one team. There was one transport, one serializer, one error type. Every type parameter had exactly one implementation. The author had written an extensible framework for a problem that didn’t need extending.</p> </article> <article> <h1>Lesson 2: Cancellation with context.Context — Every goroutine needs a kill switch</h1> <p>Sun, 13 Apr 2025 00:00:00 +0000</p> <p>Without <code>context.Context</code>, you have goroutines running long after the user who triggered them gave up, HTTP connections burning server resources for requests nobody’s waiting for, and database queries executing on behalf of clients that disconnected ten seconds ago. Context is the mechanism Go gives you to propagate “I changed my mind” — and most engineers don’t use it until something in production embarrasses them into learning it properly.</p> <h2 id="the-problem">The Problem</h2> <p>Let’s start with the most common mistake — blocking on a slow operation with no timeout:</p> </article> <article> <h1>Lesson 12: Zero-Copy Parsing — bytes, nom, winnow</h1> <p>Sat, 12 Apr 2025 11:30:00 +0000</p> <p>I once had to parse 2GB of log files per hour on a machine with 4GB of RAM. The naive approach — read line, split into fields, store as <code>String</code> — peaked at 6GB memory usage and fell over. The data was being duplicated everywhere: once in the read buffer, once in each split <code>String</code>, once in the output struct. Three copies of every byte.</p> <p>The zero-copy version peaked at 2.1GB — basically the file size plus a thin layer of parsed references. Same output, same correctness, one-third the memory, twice the throughput. Zero-copy parsing is one of the most powerful techniques in Rust’s performance toolkit, and the ownership system makes it uniquely natural here.</p> </article> <article> <h1>Lesson 7: Profiling in Containers — pprof works in Kubernetes too</h1> <p>Sat, 12 Apr 2025 00:00:00 +0000</p> <p>The first time I needed to profile a Go service in production, I assumed I’d have to deploy a special build, reproduce the problem locally, or use some heavyweight APM product. Then I learned that Go’s <code>net/http/pprof</code> package can serve live profiling data from a running process via HTTP — in a container, in Kubernetes, right now, without redeployment.</p> <p><code>pprof</code> is the built-in Go profiler. It can capture CPU profiles (what functions are consuming CPU time), heap profiles (what’s allocated in memory and by whom), goroutine profiles (how many goroutines exist and what they’re doing), and block/mutex profiles (where goroutines are waiting). All of this is available as HTTP endpoints that you can scrape with <code>go tool pprof</code> from your laptop.</p> </article> <article> <h1>Lesson 4: God Structs — When types do too much</h1> <p>Fri, 11 Apr 2025 16:10:00 +0000</p> <p>I once opened a file called <code>app.rs</code> and found a struct with forty-two fields. Forty-two. It held the database connection, the HTTP client, the cache handle, the logger, the config, the metrics collector, the rate limiter, the auth provider, the feature flags, the email sender, the template engine, and about thirty other things I’ve blocked from memory. Every function in the codebase took <code>&self</code> on this monster. Need to send an email? You need the god struct. Parse a config value? God struct. Log a message? Believe it or not, god struct.</p> </article> <article> <h1>Lesson 8: Avoiding Premature Optimization — Measure first, optimize never (usually)</h1> <p>Thu, 10 Apr 2025 00:00:00 +0000</p> <p>I’ve spent time in this series showing you how to make Go programs faster — escape analysis, stack allocation, pre-sizing data structures, zero-copy string handling, benchmarking discipline, pprof profiling, CPU vs memory tradeoffs. Every technique is real and useful. And every single one of them has been misapplied, including by me, when applied before understanding whether they were needed. The last lesson isn’t another technique. It’s the discipline that makes all the other techniques worth using: measure first, understand where the actual cost is, and optimize only there.</p> </article> <article> <h1>Lesson 3: Stringly Typed APIs — Use enums, not strings</h1> <p>Wed, 09 Apr 2025 08:47:00 +0000</p> <p>I inherited a Rust codebase once where the entire state machine was driven by string comparisons. The order status could be <code>"pending"</code>, <code>"processing"</code>, <code>"shipped"</code>, <code>"delivered"</code>, or <code>"cancelled"</code>. Except sometimes it was <code>"Pending"</code> with a capital P. And there was one code path that set it to <code>"canceled"</code> — one L, American spelling. And another that used <code>"CANCELLED"</code>. The bug lived in production for weeks because nobody could figure out why some orders were getting stuck in a phantom state that didn’t match any of the <code>if status == "cancelled"</code> checks scattered across thirty files.</p> </article> <article> <h1>Lesson 6: Avoiding Reflection — Generics and code generation often win</h1> <p>Tue, 08 Apr 2025 00:00:00 +0000</p> <p>After spending several lessons on what reflection can do, it is worth turning the question around: when should you specifically choose not to use reflection, even when it would work? The answer is almost always “when you have a statically typed alternative,” because statically typed code is faster, catches errors at compile time rather than runtime, and is easier for both humans and tools to reason about.</p> <p>Go 1.18 added generics, which eliminated one of the most common justifications for reflection: writing algorithms that work on slices, maps, or other containers of unknown element type. Code generation eliminates another: producing type-specific serializers, converters, and mappers that are faster than reflection can ever be. Knowing when to reach for these alternatives instead of reflection is part of writing mature Go.</p> </article> <article> <h1>Lesson 2: unwrap() in Production — Time bombs waiting to explode</h1> <p>Mon, 07 Apr 2025 14:35:00 +0000</p> <p>A service I was responsible for went down at 2 AM on a Saturday because of a single <code>.unwrap()</code> call on line 847 of a file nobody had touched in months. The function parsed a config value that was supposed to always be present. Somebody changed the config format in a different repo, the value became optional, and that <code>.unwrap()</code> detonated like a landmine — <code>thread 'main' panicked at 'called Option::unwrap() on a None value'</code>. Down. Dead. Pager screaming.</p> </article> <article> <h1>Lesson 11: Binary Size Reduction — Smaller deployments</h1> <p>Mon, 07 Apr 2025 13:17:00 +0000</p> <p>I shipped a “hello world” Rust binary to a team once and they came back confused: “Why is this 4 megabytes?” Fair question. A C hello-world is 16KB. A Go hello-world is about 2MB. A default Rust hello-world with standard linking is 3-4MB.</p> <p>That 4MB isn’t wasted — it’s the Rust standard library, panic handling, formatting machinery, and debug symbols. But when you’re building container images, deploying to embedded devices, or targeting WebAssembly, every megabyte counts. Here’s how to cut Rust binaries down to size.</p> </article> <article> <h1>Lesson 6: Accept Interfaces, Return Structs — Flexibility in, certainty out</h1> <p>Mon, 07 Apr 2025 00:00:00 +0000</p> <p>Here’s a mistake I see in almost every Go codebase written by people coming from Java or C#: they accept concrete types everywhere and return interfaces from constructors. It feels “enterprise-y”. It’s actually backwards. The idiomatic Go version is the opposite — accept the smallest interface that does the job, return the richest concrete type you have.</p> <h2 id="the-problem">The Problem</h2> <p>Most of the pain comes from accepting concrete types. Once you lock a function to a specific concrete type, every caller that doesn’t have exactly that type is stuck. Tests become integration tests. Swapping implementations requires rewriting functions. And the function itself becomes harder to compose.</p> </article> <article> <h1>Lesson 1: Goroutine Lifecycle Management — Who owns this goroutine?</h1> <p>Sun, 06 Apr 2025 00:00:00 +0000</p> <p>Nobody tells you that the first goroutine you “fire and forget” in production is the one that eventually takes down your service at 3 AM. You start it, it runs, and everything looks fine — until requests pile up, memory climbs, and your dashboards turn red because five hundred goroutines are blocked waiting on a channel that’ll never receive another value. The problem isn’t that goroutines are dangerous. It’s that nobody taught you to think about <em>who owns them</em>.</p> </article> <article> <h1>Lesson 1: .clone() Everywhere — Hiding ownership problems</h1> <p>Sat, 05 Apr 2025 10:22:00 +0000</p> <p>I was reviewing a pull request last year from a developer who’d been writing Rust for about three months. The code compiled. The tests passed. Everything looked fine — until I ran <code>grep -c '\.clone()' src/</code> and got back a number that made me physically uncomfortable. Forty-seven clones across six files. The codebase was a data pipeline processing millions of events per hour, and this person had turned every ownership error into a <code>.clone()</code> call until the compiler stopped yelling.</p> </article> <article> <h1>Lesson 7: Build Flags and ldflags — Inject version info at compile time</h1> <p>Sat, 05 Apr 2025 00:00:00 +0000</p> <p>A CLI tool that cannot tell you what version it is running is a frustrating tool to operate. When something breaks, the first question is “which version?” Without a proper answer, debugging becomes archaeology. The good news is that Go’s build system provides two mechanisms for injecting metadata at compile time — <code>ldflags</code> for injecting variable values from the shell, and build constraints for including or excluding code based on the build context — and both are straightforward once you understand their syntax.</p> </article> <article> <h1>Lesson 10: Compile Time Optimization — Strategies that actually work</h1> <p>Thu, 03 Apr 2025 08:55:00 +0000</p> <p>My main Rust project at work took 4 minutes and 38 seconds for a clean build. That was two years ago. Today it takes 52 seconds. Same codebase — more code, actually. Same hardware. The difference is about a dozen targeted changes, none of which involved rewriting application code.</p> <p>Rust’s compile times are its most legitimate criticism. But “Rust is slow to compile” is the starting point, not the conclusion. Most projects can cut their build times by 50-80% with the right techniques. Let me show you what actually moves the needle.</p> </article> <article> <h1>Lesson 8: Premature Abstraction — Wrong abstraction costs more than duplication</h1> <p>Wed, 02 Apr 2025 00:00:00 +0000</p> <p>There is a principle in software development — “Don’t Repeat Yourself” — that is so widely known it gets abbreviated to DRY and invoked to justify almost any abstraction. The problem is that DRY is a principle about knowledge, not syntax. Two pieces of code that look the same but represent different concepts should stay separate. Two pieces of code that represent the same concept should indeed be unified. Most premature abstractions happen when developers see syntactic similarity and immediately reach for abstraction, before they understand whether the similarity is incidental or fundamental.</p> </article> <article> <h1>Lesson 7: Kill the Utils Package — util.go is where code goes to hide</h1> <p>Tue, 01 Apr 2025 00:00:00 +0000</p> <p>Every Go codebase I’ve worked on for more than a year has a <code>util</code> package. Some have a <code>helpers</code> package. Some have both. I’ve seen <code>common</code>, <code>shared</code>, <code>misc</code>, and once, memorably, <code>stuff</code>. These packages are where code goes when a developer doesn’t know where it belongs — which means they’re the first place reviewers stop reading carefully, the last place new engineers look when they can’t find something, and the primary location of dead code in any codebase over 18 months old.</p> </article> <article> <h1>Lesson 9: Inlining — #[inline] and LTO</h1> <p>Mon, 31 Mar 2025 19:05:00 +0000</p> <p>A few years ago I was profiling a JSON parser and noticed something weird. A tiny function — four lines, no allocations — was showing up as a 15% hot spot. Not because it was slow, but because it was called 8 million times per second and the function call overhead (push registers, set up stack frame, call, pop registers, return) was eating 2 nanoseconds each call. That’s 16 milliseconds per second just in function prologues and epilogues.</p> </article> <article> <h1>Lesson 8: Cache-Friendly Data Structures — Data-oriented design</h1> <p>Sat, 29 Mar 2025 07:40:00 +0000</p> <p>Here’s a number that should change how you think about data structures: reading from L1 cache takes about 1 nanosecond. Reading from main memory takes about 100 nanoseconds. That’s a 100x penalty for a cache miss. On a modern CPU running at 4 GHz, a single cache miss stalls the processor for roughly 400 cycles. Four hundred cycles where your CPU is sitting there, doing nothing, waiting for data to arrive from RAM.</p> </article> <article> <h1>Lesson 7: Choosing the Right Collection — It's not always Vec</h1> <p>Thu, 27 Mar 2025 15:22:00 +0000</p> <p>A friend asked me to review their service that was doing “thousands of lookups per second” against a <code>Vec</code> of about 50,000 entries. Linear scan every time. They’d chosen <code>Vec</code> because “it’s the default” and hadn’t thought about it further. Swapping to a <code>HashMap</code> took the lookup from 12µs to 40ns. Three hundred times faster. From a one-line change.</p> <p>Choosing the right collection is one of the highest-leverage performance decisions you can make, and it requires basically zero cleverness. Just know your access patterns.</p> </article> <article> <h1>Lesson 6: String Performance — SmartString, CompactStr, and when to care</h1> <p>Tue, 25 Mar 2025 11:50:00 +0000</p> <p>I was building an in-memory index that stored about 2 million tag strings. Most were short — “rust”, “go”, “api”, “v2” — averaging 6 bytes. But each <code>String</code> carries 24 bytes of overhead (pointer + length + capacity) plus the heap allocation for the actual data. That’s 24 bytes of bookkeeping to store 6 bytes of useful information. Plus 2 million separate allocations hammering the allocator.</p> <p>Switching to <code>CompactStr</code> cut memory usage by 60% and index-building time by 40%. Strings matter more than you think.</p> </article> <article> <h1>Lesson 10: Test Architecture — Tests that survive refactoring</h1> <p>Tue, 25 Mar 2025 00:00:00 +0000</p> <p>Every test suite starts clean. Then the codebase grows, the team grows, deadlines hit, and gradually the tests become the thing you dread touching. You add a feature and a hundred tests break — not because the feature is wrong, but because the tests were coupled to implementation details. You rename a method and spend more time updating tests than writing the feature. Sound familiar? The problem isn’t the tests themselves. It’s the architecture — the structure, the layering, and the principles that determine whether your test suite stays an asset or becomes a liability.</p> </article> <article> <h1>Interview Patterns L17: Graph DFS — Explore everything, mark what you've seen</h1> <p>Mon, 24 Mar 2025 00:00:00 +0000</p> <p>Graph DFS is the tool you reach for when you need to explore every reachable node, not just the closest ones. Unlike BFS, which expands in rings of increasing distance, DFS commits to one direction until it cannot go further, then backtracks. This makes it naturally suited for problems where you need to visit entire connected regions, detect cycles, or trace paths between specific source and destination sets.</p> <p>The three problems in this lesson each probe a different dimension of graph DFS. Cloning a graph tests your ability to handle shared references while building a new structure. Pacific Atlantic Water Flow introduces the reverse-DFS technique — instead of asking “where can this water flow?”, you ask “which cells can reach each ocean?” Course Schedule uses DFS to detect cycles, the canonical prerequisite for topological ordering. Together they cover the non-trivial uses of graph DFS that come up in senior engineering interviews.</p> </article> <article> <h1>Lesson 5: Iterators vs Loops — Performance characteristics</h1> <p>Sun, 23 Mar 2025 09:12:00 +0000</p> <p>When I first started writing Rust, I wrote everything as <code>for</code> loops. Old habits from C. Then someone on my team rewrote one of my loops as an iterator chain and I got annoyed — it looked “slower” to me. More function calls, closures, chaining. Obviously that’s more overhead, right?</p> <p>I benchmarked it. Same performance. Down to the nanosecond. I looked at the assembly. Identical. That was the day I stopped assuming and started measuring.</p> </article> <article> <h1>Lesson 10: How rustc Works — From source code to binary</h1> <p>Sat, 22 Mar 2025 11:30:00 +0000</p> <p>A junior on my team once asked why Rust compiles so slowly compared to Go. I gave the standard answer about monomorphization and LLVM, but realized I couldn’t actually explain the full pipeline. So I spent a weekend reading the rustc dev guide and poking at compiler internals. What I found was a surprisingly elegant six-stage pipeline, and understanding it changed how I think about Rust’s design tradeoffs.</p> <h2 id="the-big-picture">The Big Picture</h2> <p>When you run <code>cargo build</code>, your source code goes through six major stages before becoming a binary:</p> </article> <article> <h1>Lesson 6: sync Package Complete Guide — Mutex, Once, Pool, Map — when to use each</h1> <p>Sat, 22 Mar 2025 00:00:00 +0000</p> <p>The <code>sync</code> package is where Go’s concurrency tools live when channels aren’t the right answer. <code>sync.Mutex</code>, <code>sync.RWMutex</code>, <code>sync.WaitGroup</code>, <code>sync.Once</code>, <code>sync.Pool</code>, <code>sync.Map</code> — each one solves a specific problem, and using the wrong one is a reliable way to introduce bugs or performance regressions. I’ve misused all of them at various points.</p> <p>The general guidance is channels for communication, mutexes for protecting shared state. But within the mutex family, the choice between Mutex, RWMutex, and sync.Map has performance implications that matter in hot paths. And sync.Pool is frequently misunderstood — it’s not a general-purpose object pool; it’s a GC-aware buffer recycler.</p> </article> <article> <h1>Lesson 4: Reducing Allocations — Stack, arena, SmallVec</h1> <p>Fri, 21 Mar 2025 16:30:00 +0000</p> <p>I profiled a Rust web service once and found it was allocating 47,000 times per request. Forty-seven thousand. Most were tiny — 16-byte strings, 3-element vectors, temporary buffers. Each individual allocation was fast (jemalloc is good), but 47,000 of them at ~30ns each is 1.4ms of pure allocator overhead. Per request. At 10K RPS that’s 14 seconds of CPU time per second, just asking the allocator for memory.</p> <p>The fix took half a day and cut allocations to about 200 per request. Here’s everything I know about reducing allocations in Rust.</p> </article> <article> <h1>Lesson 7: Outbox Pattern — Reliable events without distributed transactions</h1> <p>Thu, 20 Mar 2025 00:00:00 +0000</p> <p>Here’s a bug that’s bitten almost every distributed system I’ve worked on: a service saves a record to the database and then publishes an event to Kafka. The record is saved. The process crashes before the publish. Now the database says the order exists, but the fulfillment service never heard about it. The order sits in limbo forever.</p> <p>The naive fix — wrapping both operations in a transaction — doesn’t work because Kafka isn’t a participant in your database transaction. You can’t two-phase commit across Postgres and Kafka without a distributed transaction coordinator, and nobody wants to operate one of those in production.</p> </article> <article> <h1>Lesson 3: Profiling — perf, flamegraph, samply</h1> <p>Wed, 19 Mar 2025 10:45:00 +0000</p> <p>A colleague once asked me to look at a Rust service that was “slow.” They’d already spent a week trying to optimize the JSON parsing layer because “parsing is always the bottleneck.” I ran a profiler. Sixty-three percent of CPU time was spent in <code>Drop</code> implementations, deallocating thousands of small strings that were created and immediately discarded. The JSON parsing was 4% of runtime.</p> <p>Profiling would’ve found that in five minutes. That’s why this lesson exists.</p> </article> <article> <h1>Lesson 9: Miri — Your safety net for unsafe Rust</h1> <p>Wed, 19 Mar 2025 08:45:00 +0000</p> <p>I once shipped a Rust library with an unsafe block that worked perfectly on x86, passed all tests, and ran flawlessly in production for months. Then someone compiled it on ARM and it segfaulted immediately. The undefined behavior had been lurking the whole time — x86 just happened to tolerate the misaligned read that ARM wouldn’t. If I’d run Miri before releasing, I would have caught it in thirty seconds. Lesson learned the hard way.</p> </article> <article> <h1>Lesson 5: Debugging in Kubernetes — kubectl tricks that save hours</h1> <p>Tue, 18 Mar 2025 00:00:00 +0000</p> <p>The most stressful hours of my on-call life have been in Kubernetes clusters where something was wrong but nothing was obviously broken. Pods in <code>Pending</code> for reasons that weren’t clear. Services returning 503s but all pods showing as <code>Running</code>. Memory usage climbing slowly across a fleet for two days before things started dying. Over years of debugging production Kubernetes issues, I’ve accumulated a set of commands and mental models that cut through the noise. This article is that collection.</p> </article> <article> <h1>Lesson 2: Benchmarking with criterion and divan — Statistically rigorous benchmarks</h1> <p>Mon, 17 Mar 2025 14:18:00 +0000</p> <p>Last year I reviewed a PR where someone claimed their new serialization code was “2x faster.” Their benchmark? <code>std::time::Instant::now()</code> called once before and once after. Single run. No warmup. No statistical analysis. The “2x speedup” was thermal throttling on the first run.</p> <p>Benchmarking is harder than it looks. Let’s do it properly.</p> <h2 id="why-naive-benchmarks-lie">Why Naive Benchmarks Lie</h2> <p>Before we get into the tools, let me show you all the ways a naive benchmark can mislead you:</p> </article> <article> <h1>Lesson 5: Logging vs Returning — Log at the boundary, return everywhere else</h1> <p>Mon, 17 Mar 2025 00:00:00 +0000</p> <p>There’s a smell I encounter in almost every codebase I’ve reviewed — including ones I wrote early in my Go career. Someone discovers that <code>err != nil</code> and, out of an abundance of caution, they log it right there. Then return it. Then the caller logs it again. Then the middleware logs it a third time. By the time a single failed database query reaches the response, it’s appeared in the logs four times with slightly different messages and you can’t tell whether four things failed or one thing failed four times.</p> </article> <article> <h1>Lesson 8: Custom Allocators — GlobalAlloc, arena allocation, and beyond</h1> <p>Sun, 16 Mar 2025 13:10:00 +0000</p> <p>I was building a JSON parser that processed millions of small documents per second. Profiling showed that 40% of the time was spent in <code>malloc</code> and <code>free</code> — not parsing, not I/O, just allocating and deallocating tiny strings and vectors. Switched to an arena allocator that bulk-freed everything after each document, and throughput doubled. That experience taught me that the allocator isn’t just plumbing — it’s a performance lever.</p> <h2 id="how-rust-allocates-memory">How Rust Allocates Memory</h2> <p>When you write <code>Box::new(42)</code> or <code>Vec::with_capacity(100)</code>, Rust asks the <strong>global allocator</strong> for memory. By default, this is the system allocator — <code>malloc</code>/<code>free</code> on Unix, <code>HeapAlloc</code>/<code>HeapFree</code> on Windows. It’s a general-purpose allocator designed to handle any allocation pattern reasonably well, but it’s not optimized for any specific pattern.</p> </article> <article> <h1>Lesson 1: Performance Philosophy — Measure, don't guess</h1> <p>Sat, 15 Mar 2025 08:32:00 +0000</p> <p>I once spent three days rewriting a hot loop to avoid a single allocation per iteration. Hand-rolled a custom arena, eliminated two clones, even switched from <code>HashMap</code> to a hand-tuned open-addressing table. Benchmarked the result: 0.3% improvement. The actual bottleneck? A DNS lookup buried in a library call that I never bothered to profile.</p> <p>Three days. Zero meaningful impact. That’s the lesson I want to start this entire course with.</p> </article> <article> <h1>Lesson 8: Rate Limiting — Say no before you break</h1> <p>Sat, 15 Mar 2025 00:00:00 +0000</p> <p>A service I was running had no rate limiting. One night, a script that a client was testing started sending requests in a tight loop — about 4,000 requests per second. The database connection pool saturated within seconds. Other clients started seeing timeouts. By the time I woke up and deployed a fix, we had been degraded for forty minutes. A single <code>429 Too Many Requests</code> response would have stopped the script cold in seconds.</p> </article> <article> <h1>Lesson 7: Drop Order — Deterministic destruction and why it matters</h1> <p>Thu, 13 Mar 2025 07:20:00 +0000</p> <p>I once had a deadlock in a Rust program that only manifested during shutdown. A mutex guard and a database connection were being dropped in the wrong order — the connection’s destructor tried to acquire the mutex that was already locked by the guard that hadn’t been dropped yet. Rust’s drop order is deterministic, but “deterministic” doesn’t mean “obvious.” Knowing the rules saved me hours of debugging.</p> <h2 id="the-drop-trait">The Drop Trait</h2> <p>In Rust, cleanup logic is implemented through the <code>Drop</code> trait. When a value goes out of scope, the compiler calls <code>drop()</code> on it automatically. This is RAII — Resource Acquisition Is Initialization — borrowed from C++ but made more reliable by the ownership system.</p> </article> <article> <h1>Lesson 4: Tool Calling Patterns — Letting the LLM invoke your Go functions</h1> <p>Wed, 12 Mar 2025 00:00:00 +0000</p> <p>Tool calling is where LLM integrations get genuinely powerful. Without tool calling, you’re limited to asking the model to generate text. With tool calling, you can build a conversational interface where the model decides which of your functions to call, calls them, incorporates the results into its reasoning, and decides whether to call more tools or return a final answer. I’ve used this to build support assistants that query databases, coding assistants that run test suites, and research tools that fetch live web content — all driven by the model’s judgment about which tools to invoke.</p> </article> <article> <h1>Lesson 6: repr(C), repr(transparent), repr(packed) — Taking control of memory layout</h1> <p>Tue, 11 Mar 2025 09:55:00 +0000</p> <p>The first time I wrote Rust FFI bindings to a C library, I defined a struct, passed it across the boundary, and got garbage data back. The C side was reading fields at fixed offsets, but Rust had silently reordered my fields for padding efficiency. Took me twenty minutes of staring at hex dumps to realize the layouts didn’t match. That’s the day I learned about <code>#[repr(C)]</code>.</p> <h2 id="default-rust-layout-reprrust">Default Rust Layout: repr(Rust)</h2> <p>By default, Rust structs use <code>repr(Rust)</code> — the compiler is free to reorder fields, add padding wherever it wants, and generally optimize the layout however it sees fit. The only guarantees are:</p> </article> <article> <h1>Lesson 8: Secure HTTP Defaults — Your production server needs these headers</h1> <p>Mon, 10 Mar 2025 00:00:00 +0000</p> <p>When I run the Go HTTP server in the standard library with no configuration, it does a lot of things right — it is fast, it handles HTTP/2, it is well-tested. But it also does a handful of things that are wrong for production: no timeouts, no response headers that protect against common browser-based attacks, and server identification information in responses. These are not bugs in the standard library; they are defaults appropriate for development that need to be changed before you deploy.</p> </article> <article> <h1>Lesson 5: Fat Pointers — &dyn Trait, &[T], and &str under the hood</h1> <p>Sun, 09 Mar 2025 16:40:00 +0000</p> <p>I remember being confused why <code>&str</code> was 16 bytes on a 64-bit system. A pointer is 8 bytes — what’s the other 8? That question sent me down a rabbit hole that fundamentally changed how I think about Rust’s type system. Turns out, some references carry extra baggage, and that baggage is the entire reason dynamically sized types work.</p> <h2 id="thin-pointers-vs-fat-pointers">Thin Pointers vs Fat Pointers</h2> <p>Most references in Rust are “thin” — a single machine word pointing to the data:</p> </article> <article> <h1>Lesson 7: The io.Reader/Writer Ecosystem — The most powerful 2-method interfaces in Go</h1> <p>Sat, 08 Mar 2025 00:00:00 +0000</p> <p>If you want to understand what makes Go interfaces powerful, do not start with your own code. Start with <code>io.Reader</code>. It is one method — <code>Read(p []byte) (n int, err error)</code> — and it is the foundation of an entire ecosystem that spans files, network connections, HTTP bodies, compressed streams, encrypted data, buffered reads, pipes, test helpers, and dozens of third-party libraries. Everything that produces bytes implements <code>io.Reader</code>. Everything that consumes bytes accepts one.</p> </article> <article> <h1>Lesson 4: vtables — How dyn Trait actually works under the hood</h1> <p>Fri, 07 Mar 2025 11:15:00 +0000</p> <p>I was profiling a parser once and found that a hot path using <code>dyn Iterator</code> was 3x slower than the equivalent code using generics. The algorithm was identical. The difference? Dynamic dispatch — every method call went through a vtable lookup instead of being inlined. That day I learned to respect what <code>dyn</code> really costs. Let’s open the hood.</p> <h2 id="static-vs-dynamic-dispatch">Static vs Dynamic Dispatch</h2> <p>Rust gives you two ways to call methods on trait objects: static dispatch (generics) and dynamic dispatch (<code>dyn Trait</code>).</p> </article> <article> <h1>Interview Patterns L16: Graph BFS — Shortest path in unweighted graphs</h1> <p>Fri, 07 Mar 2025 00:00:00 +0000</p> <p>The moment someone says “shortest path” in an interview, I mentally split the problem into two cases: weighted or unweighted? If unweighted — every edge costs the same, every step is distance 1 — BFS gives the shortest path guarantee for free. No Dijkstra needed. BFS explores nodes in order of increasing distance from the source, so the first time you reach a destination, that is definitionally the shortest path.</p> </article> <article> <h1>Lesson 3: Box — Heap allocation by choice</h1> <p>Wed, 05 Mar 2025 08:30:00 +0000</p> <p>When I first started writing Rust, I used <code>Box</code> everywhere. Came from a Java background where everything lives on the heap, and wrapping things in <code>Box</code> felt natural. Took me a while to realize I was fighting the language — most of the time, you don’t need it. But when you do need <code>Box</code>, nothing else will do.</p> <h2 id="what-box-actually-is">What Box Actually Is</h2> <p><code>Box<T></code> is the simplest smart pointer in Rust. It allocates a value of type <code>T</code> on the heap and gives you ownership of that allocation through a pointer on the stack. When the <code>Box</code> goes out of scope, it frees the heap memory. That’s it. No reference counting, no garbage collection, no magic.</p> </article> <article> <h1>Lesson 7: The Complete Observability Stack — Logs, metrics, traces, profiles — wired together</h1> <p>Wed, 05 Mar 2025 00:00:00 +0000</p> <p>We have covered each signal in isolation — structured logs, Prometheus metrics, OpenTelemetry traces, correlation IDs, pprof profiles, and latency distributions. The preceding six lessons described the individual instruments. This one is about wiring them together into a system that actually works during an incident, not just in a demo.</p> <p>The goal is this: when something breaks in production, you should be able to answer four questions within five minutes: Is it broken? Who is affected? Where in the system did it break? What is the root cause? Logs, metrics, traces, and profiles each answer one of those questions. The wiring between them — shared trace IDs, consistent service names, deployment markers on dashboards — is what lets you move between signals without losing context.</p> </article> <article> <h1>Lesson 12: Macro Anti-Patterns — When not to macro</h1> <p>Tue, 04 Mar 2025 12:50:00 +0000</p> <p>I once worked on a codebase where someone had written a macro for everything. Creating structs? Macro. Implementing a two-line function? Macro. Logging? Custom logging macro that wrapped <code>println!</code> and added a timestamp. The macro definitions file was 800 lines long. The macros had macros inside them. Nobody on the team could modify them without breaking something, and the original author had left six months earlier. That project taught me more about when <em>not</em> to use macros than any tutorial ever could.</p> </article> <article> <h1>Lesson 2: Stack vs Heap — Where your data actually lives</h1> <p>Mon, 03 Mar 2025 14:45:00 +0000</p> <p>A colleague once asked me why their Rust program was ten times slower than expected. They were allocating a <code>Vec<u8></code> inside a tight loop — millions of heap allocations per second. Moved the vec outside the loop, pre-allocated with <code>with_capacity</code>, and the function went from 2 seconds to 80 milliseconds. Stack vs heap isn’t an academic distinction. It’s the difference between fast code and slow code.</p> <h2 id="two-memory-regions-two-personalities">Two Memory Regions, Two Personalities</h2> <p>Your program has (at minimum) two regions of memory to work with: the <strong>stack</strong> and the <strong>heap</strong>. They behave differently, perform differently, and serve different purposes. Rust makes the choice between them more explicit than most languages, which is one of the reasons it’s fast by default.</p> </article> <article> <h1>Lesson 5: What's New in Go 1.25–1.26 — Swiss table maps, weak pointers, and the future</h1> <p>Sun, 02 Mar 2025 00:00:00 +0000</p> <p>Every major Go release follows a rhythm: one or two headline language features, a handful of standard library additions, and a runtime improvement you probably do not notice directly but that makes your services run better in aggregate. Go 1.23 and 1.24 brought the iterator protocol, <code>go tool</code> improvements, and the <code>unique</code> package. Go 1.25 and 1.26 continued this pattern with Swiss table map internals, a production-ready weak pointer API, and improvements to the toolchain that affect how you build, ship, and profile Go binaries.</p> </article> <article> <h1>Lesson 11: Real-World Macro Patterns — serde, clap, sqlx under the hood</h1> <p>Sat, 01 Mar 2025 15:40:00 +0000</p> <p>I used <code>#[derive(Serialize)]</code> for two years before I actually looked at what it generates. When I finally ran <code>cargo expand</code> on a struct with five fields, I got 150 lines of serialization code — visitor patterns, generic bounds, field-by-field traversal, error handling. All generated from a single line. Understanding how production crates use macros changed how I think about API design. These aren’t academic exercises — they’re the patterns behind the most downloaded crates in the ecosystem.</p> </article> <article> <h1>Lesson 1: Memory Layout — Size, alignment, and the padding you never asked for</h1> <p>Sat, 01 Mar 2025 10:22:00 +0000</p> <p>I spent an embarrassing amount of time debugging a networking project where my hand-crafted packet structs were mysteriously three bytes too large. Turns out the compiler was inserting padding I didn’t know about. That’s when I realized most Rust developers — myself included — treat memory layout as a black box. Let’s crack it open.</p> <h2 id="why-layout-matters">Why Layout Matters</h2> <p>Every type in Rust has two fundamental properties: <strong>size</strong> and <strong>alignment</strong>. The size is how many bytes the value occupies. The alignment is which memory addresses the value is allowed to start at. These two numbers determine everything about how your data sits in memory, how much RAM your program uses, and whether your structs can talk to C code or hardware registers.</p> </article> <article> <h1>Lesson 7: Values Copy vs Share — When Go copies and when it doesn't</h1> <p>Sat, 01 Mar 2025 00:00:00 +0000</p> <p>Early in my Go career I had a bug where I modified a slice inside a function expecting the caller’s slice to remain unchanged — and it did. Then I had a different bug where I expected the opposite and the caller’s slice <em>was</em> modified. I had no mental model for predicting which would happen. Building that model is what this lesson is about.</p> <h2 id="the-problem">The Problem</h2> <p>Go passes everything by value. That’s the official line, and it’s true. But “by value” means different things for different types:</p> </article> <article> <h1>Lesson 4: Operational vs Domain Errors — Not all errors deserve the same treatment</h1> <p>Fri, 28 Feb 2025 00:00:00 +0000</p> <p>One of the more expensive lessons I learned was treating all errors the same. When a database connection drops, you retry. When a user sends an invalid email address, you return a 400 and explain what’s wrong. When someone tries to access a resource that doesn’t belong to them, you return a 403. These are completely different situations — different causes, different remedies, different communication needs — and collapsing them into a single <code>err != nil</code> branch produces services that retry permanent failures, expose internal details to users, and log noise that drowns out real alerts.</p> </article> <article> <h1>Lesson 10: syn and quote — Parsing and generating tokens</h1> <p>Thu, 27 Feb 2025 10:20:00 +0000</p> <p>Every time I write a proc macro without <code>syn</code> and <code>quote</code>, I regret it within twenty minutes. Raw <code>TokenStream</code> 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.</p> </article> <article> <h1>Lesson 7: go.work and Workspace Mode — Developing multiple modules without replace hacks</h1> <p>Tue, 25 Feb 2025 00:00:00 +0000</p> <p>Before <code>go.work</code> 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 <code>replace</code> directive to the application’s <code>go.mod</code>, run your tests, and then remember — always remember — to remove the <code>replace</code> before committing. I have seen <code>replace</code> directives committed to production <code>go.mod</code> files more times than I would like to admit.</p> </article> <article> <h1>Lesson 9: Function-Like Proc Macros — sql!() and friends</h1> <p>Mon, 24 Feb 2025 18:30:00 +0000</p> <p>A colleague once asked me why <code>sqlx::query!("SELECT * FROM users WHERE id = $1")</code> 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.</p> </article> <article> <h1>Lesson 8: Attribute Macros — #[my_attr] in practice</h1> <p>Sat, 22 Feb 2025 07:15:00 +0000</p> <p>I was reviewing a codebase that used Actix Web and kept seeing <code>#[get("/users")]</code> 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.</p> </article> <article> <h1>Interview Patterns L15: Tree BFS Patterns — Level by level reveals structure</h1> <p>Fri, 21 Feb 2025 00:00:00 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 7: CPU vs Memory Tradeoffs — Cache it or compute it, pick one</h1> <p>Thu, 20 Feb 2025 00:00:00 +0000</p> <p>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.</p> </article> <article> <h1>Lesson 7: Derive Macros — Custom #[derive()]</h1> <p>Wed, 19 Feb 2025 13:55:00 +0000</p> <p>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.</p> </article> <article> <h1>Lesson 7: Panic as Error Handling — Panic is for bugs, not business logic</h1> <p>Tue, 18 Feb 2025 00:00:00 +0000</p> <p>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.</p> </article> <article> <h1>Lesson 6: Procedural Macros — The three kinds</h1> <p>Mon, 17 Feb 2025 09:40:00 +0000</p> <p>The moment I realized <code>macro_rules!</code> couldn’t generate new identifier names from captured inputs, I knew I needed something more powerful. I was trying to auto-generate a <code>_builder</code> suffix for struct names — take <code>Config</code> and produce <code>ConfigBuilder</code>. 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.</p> <h2 id="what-procedural-macros-actually-are">What Procedural Macros Actually Are</h2> <p>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.</p> </article> <article> <h1>Lesson 9: Flaky Test Control — A flaky test is worse than no test</h1> <p>Sat, 15 Feb 2025 00:00:00 +0000</p> <p>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.</p> </article> <article> <h1>Lesson 5: Debugging Macros — cargo-expand and trace_macros</h1> <p>Fri, 14 Feb 2025 11:05:00 +0000</p> <p>You will write a macro that compiles, runs, and produces the wrong output. You’ll stare at the macro definition, convinced it’s correct. You’ll re-read the pattern matching rules, check the repetition operators, verify the fragment specifiers — everything looks right. And then you’ll expand the macro and realize it’s generating something completely different from what you imagined. This has happened to me more times than I’m willing to admit.</p> <p>Macro debugging is a different skill from regular debugging. You can’t set breakpoints in macro expansion. You can’t step through it. You have to <em>see</em> the generated code, and then reason backwards from there to figure out where the pattern matching went wrong.</p> </article> <article> <h1>Lesson 20: Production Async Architecture — Connection pools, retries, circuit breakers</h1> <p>Wed, 12 Feb 2025 17:09:33 +0000</p> <p>This is the lesson that ties everything together. Over the last 19 lessons, we’ve built up from mental models to executors, from channels to cancellation safety. Now it’s time to put it all into a production-grade architecture.</p> <p>I’ve run async Rust services handling tens of thousands of requests per second. The patterns in this lesson are the ones that survived contact with real traffic, real failures, and 3 AM pages. Nothing theoretical here — just battle-tested code.</p> </article> <article> <h1>Lesson 4: Macro Hygiene — Scoping and naming pitfalls</h1> <p>Wed, 12 Feb 2025 16:10:00 +0000</p> <p>I once spent an embarrassing amount of time debugging a macro that worked perfectly in one file and broke in another. Same macro, same input, different behavior. Turned out the expansion was referencing a variable called <code>result</code> — which happened to shadow a <code>result</code> variable at the call site. The macro was hygienically correct in isolation but collided with the caller’s namespace. That’s when I actually understood what “macro hygiene” means and why Rust only gets it partially right.</p> </article> <article> <h1>Lesson 6: Race Detector in CI — Run -race on every PR or ship bugs</h1> <p>Wed, 12 Feb 2025 00:00:00 +0000</p> <p>A data race is a memory safety bug. Two goroutines access the same variable without synchronization, at least one is writing, and the Go memory model makes no guarantees about what happens. In practice: values get corrupted, counters drift, maps panic at runtime. These bugs are intermittent — they appear under load, on fast machines, during deploys — and they’re nearly impossible to reproduce deterministically.</p> <p>The Go race detector is one of the most powerful debugging tools in any language ecosystem. It instruments every memory access at the compiler level and reports races precisely: the exact goroutine stacks at the moment of the conflicting accesses. But it only helps if you run it. Most teams run it once after a bug report. The right approach is running it on every PR, in CI, before the code is ever merged.</p> </article> <article> <h1>Lesson 19: Testing Async Code — Mocking time and I/O</h1> <p>Mon, 10 Feb 2025 11:28:56 +0000</p> <p>Async code is harder to test than sync code. Not because the logic is more complex, but because time, I/O, and concurrency introduce non-determinism. A test that passes 99 times and fails on the 100th is worse than a test that always fails — at least the always-failing test tells you something.</p> <p>I’ve developed a set of patterns for testing async Rust that eliminate flakiness. The key insight: mock the things that make tests non-deterministic (time, network, randomness) and let everything else run for real.</p> </article> <article> <h1>Lesson 3: Macro Pattern Matching — Repetition, fragments, and captures</h1> <p>Mon, 10 Feb 2025 08:30:00 +0000</p> <p>There’s a point when writing declarative macros where the syntax stops feeling like Rust and starts feeling like regex for code. You’re stacking repetition operators, nesting captures inside captures, and using <code>tt</code> munching to parse things the macro system was never designed to parse. It’s weird, it’s powerful, and once it clicks, you’ll wonder why you ever wrote boilerplate by hand.</p> <h2 id="repetition-operators-deep-dive">Repetition Operators Deep Dive</h2> <p>We touched on repetition in the last lesson. Now let’s get into the mechanics that actually matter when you’re building non-trivial macros.</p> </article> <article> <h1>Lesson 5: Validation Frameworks — Reflect once, validate everywhere</h1> <p>Mon, 10 Feb 2025 00:00:00 +0000</p> <p>Input validation is one of those problems that looks solved until you realize you are writing the same type of check — not nil, min length, valid email format, required when other field is set — dozens of times across dozens of handlers. Centralizing these rules without reflection means either a massive switch statement or hand-writing a validation function for every struct in your application. Reflection makes it possible to declare validation rules once, at the struct, and enforce them automatically everywhere that struct is validated.</p> </article> <article> <h1>Lesson 18: Tracing Async Code — Context propagation across .await</h1> <p>Sat, 08 Feb 2025 15:43:29 +0000</p> <p>Debugging async code with <code>println!</code> is like debugging a highway pileup by asking each car individually what happened. You get disconnected fragments — “I was going north,” “I hit something,” “I heard a crash” — but no coherent story. With 500 concurrent tasks all writing to stdout, good luck finding which log line belongs to which request.</p> <p>The <code>tracing</code> crate solves this. It gives you structured, contextual logging that follows your request across tasks, <code>.await</code> points, and even service boundaries. I switched from <code>log</code> to <code>tracing</code> three years ago and haven’t looked back.</p> </article> <article> <h1>Lesson 2: Declarative Macros — macro_rules! from zero</h1> <p>Fri, 07 Feb 2025 14:45:00 +0000</p> <p>The first macro I ever wrote was a disaster. I wanted a shorthand for creating <code>HashMap</code>s — something like <code>map!{ "a" => 1, "b" => 2 }</code>. The macro compiled. The expansion was garbage. I didn’t understand fragment specifiers, I didn’t understand repetition, and I definitely didn’t understand why the compiler kept telling me “unexpected token.” Took me a full weekend to get it right. Let me save you that weekend.</p> </article> <article> <h1>Lesson 17: Pin in Async Context — Why futures must be pinned</h1> <p>Thu, 06 Feb 2025 08:27:44 +0000</p> <p>I’ve been hand-waving around <code>Pin</code> for 16 lessons. Every time we saw <code>Pin<&mut Self></code> in a <code>poll</code> method, I said “don’t worry about it.” But now it’s time to worry about it, because without Pin, async Rust’s entire safety model falls apart.</p> <p>The good news: the mental model is simpler than it looks. The bad news: the <em>syntax</em> is still ugly. Let’s deal with both.</p> <h2 id="the-problem-pin-solves">The Problem Pin Solves</h2> <p>When the compiler turns your <code>async fn</code> into a state machine, it needs to store local variables across <code>.await</code> points. Sometimes those variables reference each other:</p> </article> <article> <h1>Lesson 6: Package Cohesion — Everything in a package should belong together</h1> <p>Thu, 06 Feb 2025 00:00:00 +0000</p> <p>Go packages are the primary unit of code organization. They determine what’s visible to whom, what gets compiled together, and — most importantly — they communicate intent to every engineer who reads the codebase. A package with high cohesion says something true and useful: “everything here is about orders” or “everything here handles HTTP middleware.” A package with low cohesion says nothing — it’s a filing cabinet where things went when nobody knew where else to put them.</p> </article> <article> <h1>Lesson 1: Why Macros — When functions aren't enough</h1> <p>Wed, 05 Feb 2025 10:22:00 +0000</p> <p>I spent three hours once writing nearly identical <code>impl</code> blocks for sixteen different numeric types. Copy, paste, change <code>i32</code> to <code>i64</code>, change <code>i64</code> to <code>u32</code>, repeat. Halfway through I started making typos. By the end I had a bug in the <code>u128</code> variant that took another hour to find. That’s the day I actually sat down and learned macros properly.</p> <h2 id="the-gap-between-functions-and-macros">The Gap Between Functions and Macros</h2> <p>Functions are great. You take some inputs, do some work, return a result. But functions operate on <em>values</em>. They can’t generate new struct definitions. They can’t implement traits for you. They can’t vary the number or types of arguments they accept. They can’t produce different code depending on what you pass them at compile time.</p> </article> <article> <h1>Lesson 6: Embedding Assets — embed.FS puts files inside your binary</h1> <p>Wed, 05 Feb 2025 00:00:00 +0000</p> <p>Before Go 1.16, embedding static assets in a Go binary required either a code generation tool that converted files to byte arrays, a third-party library like <code>packr</code> or <code>statik</code>, or shipping the files alongside the binary and reading them from disk at runtime. Each approach had real costs: generated code bloated repositories, third-party tools had to be installed separately, and shipping separate files broke the “single binary” distribution story.</p> <p>The <code>//go:embed</code> directive in Go 1.16 solved this cleanly. Files, directories, and whole asset trees can be embedded directly into the binary with a single comment and a variable declaration. Templates, SQL migrations, web assets, default configs — everything your binary needs can travel with it.</p> </article> <article> <h1>Lesson 16: How Async Executors Work Under the Hood — Demystifying the runtime</h1> <p>Tue, 04 Feb 2025 13:56:18 +0000</p> <p>There’s a moment in every async Rust developer’s journey where the runtime stops being a black box and starts being a machine you understand. For me, it was when I built a toy executor from scratch. Suddenly, <code>Waker</code>, <code>Context</code>, <code>poll_ready</code> — all of it made sense. Not as abstract concepts, but as mechanical parts.</p> <p>This lesson won’t make you build a production executor. But it will show you how the pieces fit together, and that understanding will change how you write and debug async code.</p> </article> <article> <h1>Lesson 3: Wrapping Strategy — Every wrap should add context, never noise</h1> <p>Tue, 04 Feb 2025 00:00:00 +0000</p> <p>There’s a certain kind of error message I’ve come to dread in production logs: <code>auth: db: sql: connection refused</code>. Technically, it contains the full path from the handler down to the socket. Practically, it tells me nothing I couldn’t figure out from the stack trace — and it takes ten seconds to parse. That error message is the output of wrapping done wrong: every layer added its name reflexively, without thinking about what the reader actually needs.</p> </article> <article> <h1>Lesson 15: Backpressure — Bounded channels and flow control</h1> <p>Sun, 02 Feb 2025 10:33:45 +0000</p> <p>The fastest way to kill a production service is to accept work faster than you can process it. I learned this the hard way when a log ingestion pipeline I built consumed 50GB of RAM and crashed because I used unbounded channels everywhere. “It works fine in testing” — yeah, testing with 100 messages, not 10 million.</p> <p>Backpressure is the mechanism by which a system says “slow down, I’m full.” Without it, fast producers overwhelm slow consumers, and your only flow control is the OOM killer.</p> </article> <article> <h1>Lesson 7: Timeouts and Retries — Your client needs a deadline, your server needs a budget</h1> <p>Sat, 01 Feb 2025 00:00:00 +0000</p> <p>I once watched a service die in slow motion. An upstream dependency started responding slowly — not failing, just slow. Within minutes, all request goroutines were blocked waiting for the upstream. New requests kept arriving. Goroutines piled up. Memory climbed. Eventually the process was killed by the kernel. The upstream recovered in about thirty seconds. My service was down for twelve minutes. Every second of that outage was caused by the absence of a single line: a timeout.</p> </article> <article> <h1>Lesson 14: Tower — The service middleware pattern</h1> <p>Fri, 31 Jan 2025 19:18:37 +0000</p> <p>I avoided Tower for months. The trait bounds looked terrifying, the documentation assumed you already knew what you were doing, and I couldn’t figure out why I’d want it when I could just write functions. Then I needed to add logging, retries, timeouts, and rate limiting to every HTTP handler in a service with 40 endpoints.</p> <p>Writing those as middleware that composes? That’s Tower’s whole thing. And once it clicks, you’ll never build a service without it.</p> </article> <article> <h1>Lesson 13: Building HTTP Clients with reqwest — Async HTTP done right</h1> <p>Thu, 30 Jan 2025 16:42:09 +0000</p> <p>Almost every backend service I’ve built makes HTTP calls to <em>something</em> — a third-party API, another microservice, a webhook endpoint. And almost every production HTTP bug I’ve dealt with comes from one of three things: missing timeouts, not reusing connections, or ignoring response bodies.</p> <p>reqwest is the HTTP client for async Rust. It’s built on hyper and Tokio, handles connection pooling, TLS, cookies, compression, and all the stuff you don’t want to think about. But you still need to use it correctly.</p> </article> <article> <h1>Interview Patterns L14: Tree DFS Patterns — Every path question is DFS</h1> <p>Thu, 30 Jan 2025 00:00:00 +0000</p> <p>If a binary tree problem asks anything about paths — longest, shortest, sum along a path, common ancestor between two nodes — the solution is almost certainly DFS. Not because DFS is the only way, but because path problems require you to propagate information up from leaves to ancestors, and that is exactly what post-order DFS does. You compute the answer for children before combining it for the parent.</p> <p>What I find interesting about this cluster of problems is how they reveal a single reusable DFS skeleton. Once you internalize the pattern — recurse left, recurse right, combine and return — you can adapt it to maximum depth, path sum, diameter, and LCA with only surface-level changes. The thinking cost drops dramatically once you stop treating each problem as novel and start asking “what do I return from each recursive call, and how do I combine it?”</p> </article> <article> <h1>Lesson 12: Async I/O — Files, sockets, DNS</h1> <p>Tue, 28 Jan 2025 08:55:13 +0000</p> <p>Here’s an uncomfortable truth about async file I/O: on most operating systems, it doesn’t really exist. When you call <code>tokio::fs::read_to_string</code>, Tokio dispatches the operation to a thread pool because Linux’s file I/O isn’t truly asynchronous (yes, there’s io_uring, but Tokio doesn’t use it by default). Network I/O, on the other hand, is genuinely async through epoll/kqueue.</p> <p>Understanding this distinction matters. It changes how you architect things.</p> <h2 id="the-async-io-traits">The Async I/O Traits</h2> <p>Tokio defines two core traits that mirror their std counterparts:</p> </article> <article> <h1>Lesson 4: Distributed Tracing — Follow the request across 5 services</h1> <p>Tue, 28 Jan 2025 00:00:00 +0000</p> <p>Debugging a microservices system with only logs is like debugging a multi-threaded program with only print statements — possible, but painful in ways that are entirely avoidable. The first time I had to trace a slow request through six services using log grep, I understood why distributed tracing exists. An hour of log correlation that should have been a 10-second click on a flame chart. Distributed tracing gives you that flame chart.</p> </article> <article> <h1>Lesson 11: Timeouts, Deadlines, and Graceful Shutdown — Bounded operations</h1> <p>Sun, 26 Jan 2025 12:24:51 +0000</p> <p>Every production outage I’ve investigated boils down to one of two things: unbounded retries or missing timeouts. A function that “usually takes 50ms” eventually takes 30 seconds because the database is overloaded, and suddenly your entire service is frozen because every thread is waiting on that one slow call.</p> <p>Timeouts aren’t optional in production code. They’re as important as error handling. And graceful shutdown — cleanly stopping your service when it’s time to deploy — is what separates “my service runs in production” from “my service runs in production <em>well</em>.”</p> </article> <article> <h1>Lesson 6: Eventual Consistency — Your data will be wrong, temporarily</h1> <p>Sat, 25 Jan 2025 00:00:00 +0000</p> <p>I used to believe that eventual consistency was an exotic property of distributed databases that I’d only encounter at Google scale. Then I added a Redis cache to a simple CRUD service and immediately had a bug where users couldn’t see their own updates. Welcome to eventual consistency — it shows up the moment you have two places that store the same data.</p> <p>Eventual consistency means that if you stop writing to a system, all replicas will eventually converge to the same value. The word “eventually” can mean milliseconds or minutes, depending on the system. The hard part isn’t the definition — it’s designing application code that works correctly even when replicas haven’t converged yet.</p> </article> <article> <h1>Lesson 10: Cancellation Safety — The silent footgun</h1> <p>Fri, 24 Jan 2025 09:41:22 +0000</p> <p>This is the lesson I wish someone had shoved in my face before I wrote my first <code>select!</code> loop. I lost three days to a bug where messages were disappearing from a queue. No errors. No panics. Just… gone. Turns out, <code>select!</code> was cancelling a future that had already read the message from the channel but hadn’t finished processing it.</p> <p>Cancellation safety is the most under-discussed footgun in async Rust. If you use <code>select!</code>, you need to understand this.</p> </article> <article> <h1>Lesson 9: Semaphores and Rate Limiting — Bounded async concurrency</h1> <p>Wed, 22 Jan 2025 15:08:36 +0000</p> <p>I once crashed a third-party API by spawning 10,000 concurrent requests from an async Rust service. The code was correct — every request completed (eventually). But the API’s rate limiter kicked in after 50 concurrent connections, and we got IP-banned for two hours.</p> <p>The fix was a single type: <code>tokio::sync::Semaphore</code>. Five lines of code turned “as fast as possible” into “at most N at a time.”</p> <h2 id="whats-a-semaphore">What’s a Semaphore?</h2> <p>A semaphore is a counter with a maximum value. You acquire a permit before doing work, and release it when you’re done. If all permits are taken, acquiring blocks (yields) until one becomes available.</p> </article> <article> <h1>Lesson 5: os and filepath — Cross-platform file operations that actually work</h1> <p>Wed, 22 Jan 2025 00:00:00 +0000</p> <p>Go’s <code>os</code> and <code>path/filepath</code> packages are among the most underappreciated in the standard library. Most developers know <code>os.Open</code>, <code>os.Create</code>, and <code>os.ReadFile</code>. Far fewer know <code>os.MkdirAll</code>, <code>os.CreateTemp</code>, <code>filepath.WalkDir</code>, or the difference between <code>path</code> and <code>path/filepath</code> — which is the difference between code that works everywhere and code that silently breaks on Windows.</p> <p>I maintain a CLI tool that runs on macOS, Linux, and Windows. The file operation bugs I’ve shipped have taught me exactly which parts of these packages require care.</p> </article> <article> <h1>Lesson 8: Async Mutexes — tokio::sync::Mutex vs std</h1> <p>Mon, 20 Jan 2025 07:15:44 +0000</p> <p>“Should I use <code>tokio::sync::Mutex</code> or <code>std::sync::Mutex</code> in async code?” I’ve seen this question in every Rust Discord server, every forum, every team Slack. And the answer most people give — “always use the async one in async code” — is wrong.</p> <p>The real answer depends on how long you hold the lock and whether you need to <code>.await</code> while holding it. Get this wrong and you’ll either deadlock your runtime or tank your performance.</p> </article> <article> <h1>Lesson 8: Race-Aware Tests — If it passes without -race, it hasn't passed</h1> <p>Mon, 20 Jan 2025 00:00:00 +0000</p> <p>A test suite that passes without <code>-race</code> is not a clean bill of health. It’s a test suite that hasn’t checked one of the most insidious categories of bugs in Go: data races. I’ve shipped code that passed every test, passed code review, and then caused memory corruption in production because two goroutines were reading and writing a map concurrently. The race detector would have found it in under a second. We just never ran it.</p> </article> <article> <h1>Lesson 7: Async Channels — tokio::sync::mpsc</h1> <p>Sat, 18 Jan 2025 13:52:28 +0000</p> <p>The first real async service I built had a classic architecture: an HTTP handler receives a request, puts work on a queue, a background worker processes it, and the result gets sent back. In Go, this is channels all day. In async Rust, it’s <em>also</em> channels — but you’ve got four different kinds to choose from, and picking the wrong one leads to subtle bugs.</p> <p>This lesson covers all four of Tokio’s channel types and when to reach for each one.</p> </article> <article> <h1>Lesson 7: JWT Caveats — JWTs are not sessions</h1> <p>Sat, 18 Jan 2025 00:00:00 +0000</p> <p>JWT has become the default answer to “how should I handle authentication tokens?” in the Go community. I have shipped JWTs in production and I have also shipped systems that would have been much simpler and more secure with server-side sessions. The point of this lesson is not that JWTs are bad — it is that they carry specific security risks that are easy to overlook, and they solve a specific problem (stateless authentication across services) that not every application actually has.</p> </article> <article> <h1>Lesson 6: Streams — Async iterators</h1> <p>Thu, 16 Jan 2025 10:31:07 +0000</p> <p>Regular iterators give you one value at a time, synchronously. Futures give you one value, asynchronously. Streams give you <em>multiple</em> values, asynchronously. It’s the obvious combination, and once you start using them, you’ll wonder how you ever processed sequences of async data without them.</p> <p>I first needed streams when building a log aggregator. I had dozens of log sources, each producing lines at their own pace. I needed to merge them, filter them, and process them in real time. Without streams, that code was a tangled mess of channels and select loops. With streams, it was a pipeline.</p> </article> <article> <h1>Interview Patterns L13: Tree Construction — Build trees from traversal arrays</h1> <p>Thu, 16 Jan 2025 00:00:00 +0000</p> <p>Construction problems break the mold. Most tree problems ask you to read a tree and return something — a traversal, a value, a boolean. Construction problems ask you to create a tree from some compact representation. That reversal in direction exposes a different set of thinking skills: can you reason backwards from output to structure? Can you identify what information each traversal encoding uniquely determines?</p> <p>I think of tree construction as a test of how well you understand what information each traversal preserves and destroys. Inorder alone cannot reconstruct a tree. Preorder alone cannot either. But together they contain exactly enough information. Serialize/deserialize is a different angle: design your own encoding so reconstruction is unambiguous. Both problems show up at Google, Meta, and Amazon with surprising regularity.</p> </article> <article> <h1>Lesson 6: Debugging Latency and Leaks — Your p99 is lying to you</h1> <p>Wed, 15 Jan 2025 00:00:00 +0000</p> <p>We had a service whose p99 latency was 800ms. The p50 was 12ms. The SLA was 200ms at p99. All our dashboards showed the p99 breaching during peak traffic, but the service felt fine to most users. We added caching. We optimized the slow database query. We bumped the CPU allocation. The p99 barely moved.</p> <p>Three weeks of tuning later, a colleague asked me to show him the raw histogram buckets. We looked at the actual distribution: 98% of requests were under 15ms. The remaining 2% were all clustered around 900ms, nearly a bimodal distribution. This was not a “slow” service — it was a service with two distinct response time populations, and the p99 was sampling from the slow population. The fix had nothing to do with the code on the hot path.</p> </article> <article> <h1>Lesson 5: tokio::select! — Racing futures</h1> <p>Tue, 14 Jan 2025 16:19:55 +0000</p> <p>A couple months ago I was building a WebSocket handler that needed to do three things simultaneously: read from the socket, check a shutdown signal, and send periodic heartbeats. With <code>join!</code>, I’d need all three to complete. But I didn’t want them all to complete — I wanted to react to whichever one happened <em>first</em>.</p> <p>That’s what <code>select!</code> does. It races multiple futures and gives you the result of the winner. The losers are dropped.</p> </article> <article> <h1>Lesson 4: Spawning Tasks and JoinHandles — Concurrent work units</h1> <p>Sun, 12 Jan 2025 08:44:19 +0000</p> <p>I remember the exact moment async Rust “clicked” for me. I was building an API aggregator that needed to call five different services. My first version awaited them sequentially — 2 seconds total. Then I spawned them as concurrent tasks — 400ms. Same work, 5x faster, and I didn’t need to think about threads, locks, or shared state.</p> <p>But spawning tasks isn’t free, and <code>JoinHandle</code> has some sharp edges that nobody warned me about. This lesson covers the patterns you’ll use every day.</p> </article> <article> <h1>Lesson 6: Swallowing Errors — The silent failure that cost us 3 hours</h1> <p>Sun, 12 Jan 2025 00:00:00 +0000</p> <p>We had a deployment where user preferences stopped being saved. New preferences were accepted by the API — the endpoint returned 200 — but nothing was written to the database. After three hours of debugging we found it: a <code>defer rows.Close()</code> inside a transaction helper that was discarding the error from <code>tx.Commit()</code>. The commit was failing silently, the defer returned without error, and the handler sent a success response. The only indication anything was wrong was a metrics counter nobody had set up an alert for.</p> </article> <article> <h1>Lesson 3: Tokio — The runtime that powers async Rust</h1> <p>Fri, 10 Jan 2025 11:05:33 +0000</p> <p>Every async Rust tutorial shows you <code>#[tokio::main]</code> in the first example and then moves on like that’s totally self-explanatory. It’s not. That macro hides a <em>lot</em> of important decisions, and if you don’t understand what it’s doing, you’re going to make some costly mistakes.</p> <p>I once spent an entire day debugging a deadlock that happened because I was using the single-threaded runtime without realizing it. One <code>#[tokio::main(flavor = "current_thread")]</code> vs the default, and my entire application’s behavior changed. That shouldn’t surprise anyone — but it surprised me.</p> </article> <article> <h1>Lesson 2: errors.Is and errors.As — Matching errors through the wrapping chain</h1> <p>Thu, 09 Jan 2025 00:00:00 +0000</p> <p>Go 1.13 shipped what I consider the most important error-handling improvement the language has had: <code>errors.Is</code>, <code>errors.As</code>, and the <code>%w</code> verb. Before that, wrapping errors with context meant breaking the ability to inspect them. You’d wrap with <code>fmt.Errorf("context: %v", err)</code> and then the original error was gone — you could log it, but you couldn’t match it. Callers would resort to string matching or just give up and let every error map to a 500.</p> </article> <article> <h1>Lesson 2: The Future Trait — What .await actually does</h1> <p>Wed, 08 Jan 2025 14:37:42 +0000</p> <p>After I understood the mental model from lesson 1, my next question was obvious: what happens <em>mechanically</em> when I write <code>.await</code>? I could accept “it’s a state machine” as a hand-wave, but I wanted to see the gears turning.</p> <p>Turns out, the answer is beautifully simple once you strip away the syntax sugar. The entire async machinery in Rust boils down to one trait, two types, and a contract.</p> <h2 id="the-future-trait-for-real-this-time">The Future Trait, For Real This Time</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">use</span> std::pin::Pin; </span></span><span style="display:flex;"><span><span style="color:#66d9ef">use</span> std::task::{Context, Poll}; </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">pub</span> <span style="color:#66d9ef">trait</span> Future { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">type</span> <span style="color:#a6e22e">Output</span>; </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">poll</span>(self: <span style="color:#a6e22e">Pin</span><span style="color:#f92672"><&</span><span style="color:#66d9ef">mut</span> Self<span style="color:#f92672">></span>, cx: <span style="color:#66d9ef">&</span><span style="color:#a6e22e">mut</span> Context<span style="color:#f92672"><</span>'_<span style="color:#f92672">></span>) -> <span style="color:#a6e22e">Poll</span><span style="color:#f92672"><</span>Self::Output<span style="color:#f92672">></span>; </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>Three things to note:</p> </article> <article> <h1>Lesson 6: Memory Alignment and Struct Padding — Field order affects struct size</h1> <p>Wed, 08 Jan 2025 00:00:00 +0000</p> <p>I once reviewed a PR where someone had defined a struct with a bool field between two int64 fields, resulting in a 24-byte struct instead of the 17 bytes you might naively calculate. When I pointed it out, the response was “the compiler should handle that.” It doesn’t. Go respects the field order you give it, and it inserts padding to satisfy alignment requirements. Knowing the rules means you write efficient structs by default.</p> </article> <article> <h1>Lesson 1: Async Mental Model — Futures, not threads</h1> <p>Mon, 06 Jan 2025 09:22:14 +0000</p> <p>I spent three weeks writing async Rust code that compiled, ran, and produced correct results — while having absolutely no idea what was actually happening. I was copy-pasting <code>async fn</code>, slapping <code>.await</code> on things, and hoping for the best. Sound familiar?</p> <p>The problem wasn’t syntax. The problem was that I was thinking about async Rust the same way I thought about threads in Go or Java. And that mental model is <em>wrong</em> for Rust.</p> </article> <article> <h1>Lesson 6: Testability Without Over-Mocking — Fakes beat mocks every time</h1> <p>Mon, 06 Jan 2025 00:00:00 +0000</p> <p>Mock frameworks are a seductive solution to a real problem. You have a dependency — a database, an email service, an HTTP client — and you need your tests to run without it. A mock framework promises to solve this with generated code and assertion APIs. In my experience, what actually happens is that the tests become tightly coupled to implementation rather than behavior, they break whenever you refactor internals, and maintaining the mock library becomes a part-time job.</p> </article> <article> <h1>Lesson 6: pprof Deep Dive — CPU, memory, goroutine — read all three</h1> <p>Sun, 05 Jan 2025 00:00:00 +0000</p> <p>When I first learned about <code>pprof</code>, I thought it was a single tool that told you “what’s slow.” It took me an embarrassingly long time to understand that it’s actually a family of profilers — CPU, heap, allocs, goroutine, mutex, block — each answering a completely different question. Reading one profile and ignoring the others is like diagnosing engine trouble by only checking the oil. You might find something. You’ll definitely miss something. The profilers are designed to work together, and once you start reading all three, performance diagnosis goes from guesswork to diagnosis.</p> </article> <article> <h1>Lesson 4: Operators and CRDs — Extending Kubernetes with your own resources</h1> <p>Fri, 03 Jan 2025 00:00:00 +0000</p> <p>I used to manage PostgreSQL on Kubernetes with a collection of shell scripts and Helm hooks. Provisioning a new database instance meant running a script that created a StatefulSet, a Service, a ConfigMap, a Secret, and set up replication. Failover meant manually triggering another script. Backups were a cron job that required careful coordination with the stateful set. Every operational task was a script that a human had to run, remember, and maintain. Then I discovered the Zalando Postgres Operator, and I understood what the Operator pattern is actually for: encoding human operational knowledge into the Kubernetes control plane itself.</p> </article> <article> <h1>Lesson 6: Dependency Direction — Always depend inward, never outward</h1> <p>Thu, 02 Jan 2025 00:00:00 +0000</p> <p>We fixed cycles in lesson 2. But removing cycles is a necessary condition for good architecture, not a sufficient one. You can have a perfectly cycle-free dependency graph where every arrow points in the wrong direction, and the result is still a system that is painful to test, extend, and reason about.</p> <p>Dependency direction is about more than just “does A import B.” It is about which layer owns the core business rules and which layers are allowed to know about which other layers. Get this wrong and your domain logic ends up tangled with your database driver. Get it right and you can replace your entire HTTP layer, or swap Postgres for a different store, without changing a single line of business logic.</p> </article> <article> <h1>Interview Patterns L12: BST Operations — Sorted order hides in every BST</h1> <p>Sun, 29 Dec 2024 00:00:00 +0000</p> <p>BST problems are deceptively simple on the surface. The property is easy to state: every node’s left subtree contains only values less than it, every right subtree contains only values greater. You have known this since your data structures course. But FAANG interviewers do not ask you to recite the definition — they probe the edge cases, the constraints that cascade from parent to child rather than just between a node and its immediate children, and the elegant iterator pattern that wraps inorder traversal in an on-demand API.</p> </article> <article> <h1>Lesson 25: Production Concurrency Architecture — Putting it all together</h1> <p>Sun, 22 Dec 2024 10:00:00 +0000</p> <p>After 24 lessons of building blocks, let’s talk about how they compose in real systems. I’ve shipped concurrent Rust services handling millions of requests per day, and the architecture patterns that survive production are surprisingly consistent. Not because they’re clever — because they’re boring. Boring is good when your pager is involved.</p> <p>This lesson is the blueprint I wish I’d had when I started building concurrent Rust systems for real.</p> </article> <article> <h1>Lesson 24: Testing Concurrent Code — Loom and beyond</h1> <p>Sat, 21 Dec 2024 09:15:00 +0000</p> <p>I spent a full week writing tests for a lock-free queue. Ran them a thousand times — all green. Shipped it. Two days later, a production crash. A race condition that occurred roughly once every 50,000 operations under specific timing. My tests never hit it because standard testing can’t explore all possible thread interleavings. That’s when I found Loom.</p> <p>Testing concurrent code is fundamentally different from testing sequential code. A test that passes doesn’t mean the code is correct — it means the code was correct <em>for that particular thread scheduling</em>. Run the same test with different timing and you might get a different result.</p> </article> <article> <h1>Lesson 4: Code Generation — From AST to bytecode or machine code</h1> <p>Fri, 20 Dec 2024 00:00:00 +0000</p> <p>The tree-walking interpreter in Lesson 3 works, but it has a ceiling. Every time you evaluate an expression, you traverse the AST from scratch. No caching, no precomputed form, no optimization. For a REPL or a small scripting language this is fine. For a production language runtime — something that runs for hours, executes millions of operations — you want a tighter inner loop. That tighter loop is a virtual machine executing bytecode. And the step that produces bytecode from the AST is code generation.</p> </article> <article> <h1>Lesson 23: GPU Computing from Rust — wgpu and compute shaders</h1> <p>Thu, 19 Dec 2024 11:35:00 +0000</p> <p>The first time I ran a matrix multiplication on a GPU, my jaw dropped. A computation that took 8 seconds on an 8-core CPU finished in 40 milliseconds on a mid-range GPU. That’s a 200x speedup. GPUs have thousands of cores — small, simple cores designed for massively parallel uniform computation.</p> <p>Rust’s GPU story has gotten remarkably good. <code>wgpu</code> gives you cross-platform GPU compute that works on Vulkan, Metal, DX12, and even in the browser via WebGPU. No CUDA lock-in.</p> </article> <article> <h1>Lesson 3: Streaming Responses — Token-by-token output without buffering the whole response</h1> <p>Wed, 18 Dec 2024 00:00:00 +0000</p> <p>If you’ve ever used a non-streaming LLM endpoint in a user-facing feature, you know the experience it creates: the user submits a question, watches a spinner for 8 seconds, then suddenly gets a wall of text. Streaming changes this completely — the user sees output appearing word by word, which feels responsive and alive even when the total time-to-complete is identical. In Go, streaming LLM responses means reading Server-Sent Events (SSE) from the API and piping them to the client in real time. It’s genuinely one of the nicer concurrency patterns I’ve implemented.</p> </article> <article> <h1>Lesson 22: SIMD — Explicit vectorization</h1> <p>Tue, 17 Dec 2024 08:20:00 +0000</p> <p>I had an image processing pipeline that took 4.2 seconds per frame on a single core. After rewriting the hot loop with SIMD intrinsics, it dropped to 0.9 seconds. Same core, same algorithm, 4.7x faster. SIMD doesn’t add more cores — it makes each core do more work per clock cycle.</p> <p>SIMD (Single Instruction, Multiple Data) is the other kind of parallelism. While threads run code on different cores, SIMD runs the same operation on multiple data elements simultaneously within a single core.</p> </article> <article> <h1>Interview Patterns L11: Binary Tree Traversal — Four ways to walk a tree, four different answers</h1> <p>Tue, 17 Dec 2024 00:00:00 +0000</p> <p>The moment an interviewer draws a binary tree on the whiteboard, a clock starts. They are not just testing whether you know what inorder means. They are watching how you think about state, iteration, and the relationship between recursive and iterative logic. Four traversal orders — preorder, inorder, postorder, level order — each reveals something different about the tree. Knowing which one to reach for, and being able to implement it iteratively without hesitation, is what separates candidates who get offers from candidates who get “we’ll be in touch.”</p> </article> <article> <h1>Lesson 21: CSP-Style Concurrency — Go channels in Rust</h1> <p>Sun, 15 Dec 2024 10:40:00 +0000</p> <p>Before I wrote Rust full-time, I spent two years writing Go. The goroutine-plus-channel model gets into your brain. You start thinking about problems as independent processes connected by typed pipes. When I switched to Rust, the first thing I looked for was the equivalent of Go’s <code>select</code> statement. Crossbeam has it — and in some ways it’s even better.</p> <p>CSP (Communicating Sequential Processes) is the formal model behind Go’s concurrency. The idea: concurrent processes interact only by passing messages through channels. No shared memory. Each process is sequential internally. Concurrency comes from composition.</p> </article> <article> <h1>Lesson 5: CI/CD for Go — GitHub Actions that actually catch bugs</h1> <p>Sun, 15 Dec 2024 00:00:00 +0000</p> <p>I’ve set up CI pipelines for Go services about a dozen times, and every iteration taught me something about what the pipeline should actually catch. The first version ran <code>go test ./...</code> and called it done. That caught compilation errors and test failures, but not data races, not staticcheck warnings, not formatting drift, not license issues, not security vulnerabilities in dependencies. Each of those failure categories has caused a production incident at some point. The current version catches most of them before the PR is merged.</p> </article> <article> <h1>Lesson 1: Sentinel vs Typed Errors — Know your error before you handle it</h1> <p>Sat, 14 Dec 2024 00:00:00 +0000</p> <p>When I first started writing Go seriously, I treated errors like fire: try to avoid them, and when you can’t, put them out as fast as possible with an <code>if err != nil { return err }</code>. It took a few production incidents — and a lot of reading other people’s codebases — before I understood that errors aren’t just signals. They’re data. And how you design that data determines how well your callers can respond to failures.</p> </article> <article> <h1>Lesson 20: The Actor Model with Rust — Message-passing architectures</h1> <p>Fri, 13 Dec 2024 14:20:00 +0000</p> <p>The first time I saw Erlang’s actor model, I thought it was over-engineered. Every piece of state behind a process, every interaction a message. Then I worked on a system with 40 mutexes, 12 deadlock-prone code paths, and a debugging story that involved printf-ing thread IDs into a file and diffing them. I became an actor model convert that week.</p> <p>Rust doesn’t have a built-in actor system like Erlang or Akka. But the building blocks — channels, threads, ownership transfer — make building one surprisingly natural.</p> </article> <article> <h1>Lesson 4: Recommendation Systems — Collaborative filtering, embeddings, and the cold start problem</h1> <p>Fri, 13 Dec 2024 00:00:00 +0000</p> <p>Recommendation systems are the most economically consequential ML systems most engineers will ever build. Netflix estimates that its recommendation system saves over a billion dollars per year in avoided cancellations. Amazon’s “customers who bought this also bought” drives a significant fraction of its revenue. Spotify’s Discover Weekly has become a user retention flywheel. The stakes are real, and the engineering is genuinely interesting.</p> <p>I got deep into recommendation systems when I was working on a content platform that had about 500,000 items and needed to surface relevant content for each user without overwhelming the ranking team with engineering requests. What I found was that the architecture of a production recommender is almost always the same shape, regardless of the domain — and the hardest problem is not the ML, it’s the cold start.</p> </article> <article> <h1>Lesson 4: Structured Logging with slog — The stdlib logger Go always needed</h1> <p>Thu, 12 Dec 2024 00:00:00 +0000</p> <p>I have switched logging libraries in Go more times than I care to admit. Started with the standard <code>log</code> package — fine for scripts, useless in production because you cannot query plain text logs efficiently. Moved to <code>logrus</code> because everyone was using it. Switched to <code>zap</code> when I needed better performance. Considered <code>zerolog</code> when I wanted allocation-free hot paths. Each migration meant updating every file that imported the old library, convincing teammates, and writing bridge adapters for third-party code that used a different logger.</p> </article> <article> <h1>Lesson 19: Thread-Local Storage — Per-thread state</h1> <p>Wed, 11 Dec 2024 09:55:00 +0000</p> <p>I was optimizing a JSON serializer that allocated a buffer for every call. Under profiling, those allocations were 30% of the cost. The fix? A thread-local buffer that gets reused across calls on the same thread. No synchronization needed. No contention. Each thread has its own buffer. Throughput doubled.</p> <p>Thread-local storage is the ultimate escape hatch from synchronization overhead. If each thread has its own copy, there’s nothing to synchronize.</p> </article> <article> <h1>Lesson 5: Cross-Compilation — Build for Linux from your Mac in one command</h1> <p>Tue, 10 Dec 2024 00:00:00 +0000</p> <p>One of Go’s most practical superpowers is that cross-compilation is a first-class feature, not an afterthought. Two environment variables — <code>GOOS</code> and <code>GOARCH</code> — are all you need to produce a Linux binary from macOS, a Windows executable from Linux, or an ARM binary from an x86 machine. No Docker containers required, no cross-compilation toolchain setup, no linker flags hunting. Just <code>GOOS=linux GOARCH=amd64 go build</code> and you have a production-ready binary for the target platform.</p> </article> <article> <h1>Lesson 18: Debugging Deadlocks and Data Races — Tools and techniques</h1> <p>Mon, 09 Dec 2024 11:30:00 +0000</p> <p>The worst deadlock I ever encountered wasn’t between two mutexes. It was between a mutex and a channel. Thread A held a lock and tried to send on a full bounded channel. Thread B was the consumer for that channel but was waiting to acquire the same lock before it could receive. Clean deadlock. Took me four hours to find because I was looking at mutex ordering and the real problem was a channel.</p> </article> <article> <h1>Lesson 6: Idempotency in APIs — Every POST should be safe to retry</h1> <p>Sun, 08 Dec 2024 00:00:00 +0000</p> <p>A client sends a payment request. The network times out. The client does not know if the payment was processed. Should it retry? If it retries and the payment already went through, the customer gets charged twice. If it does not retry and the payment failed, the order never ships. Without idempotency, there is no safe answer to this question.</p> <p>This is not a theoretical concern. It happens every time a mobile app retries a failed request, every time a message queue delivers a message at least once, every time a load balancer retries on a 503.</p> </article> <article> <h1>Lesson 17: Lock-Free Data Structures in Rust — Beyond mutexes</h1> <p>Sat, 07 Dec 2024 08:50:00 +0000</p> <p>A few years ago I was profiling a metrics collection service and found that 60% of the CPU time was spent on mutex contention. Thirty-two threads, one mutex protecting a counter map. The actual “work” — incrementing counters — took nanoseconds. The locking overhead was three orders of magnitude more expensive than the operation it protected.</p> <p>That’s when lock-free data structures become worth the complexity. When the lock is the bottleneck, remove the lock.</p> </article> <article> <h1>Lesson 3: GraphQL in Go — gqlgen, resolvers, and DataLoader for N+1</h1> <p>Sat, 07 Dec 2024 00:00:00 +0000</p> <p>Go is not the most common language for GraphQL tutorials. Most of the ecosystem documentation assumes you’re working in JavaScript or TypeScript, and a lot of the tooling is designed around Node’s event loop model. But Go is an excellent choice for a GraphQL server — statically typed, fast, and with gqlgen you get one of the cleanest schema-first GraphQL implementations I’ve used in any language.</p> <p>This lesson is about making it work in production: generating a working server from a schema, implementing resolvers correctly, and fixing the N+1 problem with DataLoader before it shows up in your latency graphs.</p> </article> <article> <h1>Lesson 5: Small Functions Win — If you can''t name it clearly, it does too much</h1> <p>Fri, 06 Dec 2024 00:00:00 +0000</p> <p>There is a simple test I apply to any function I’m about to merge: can I name it clearly without using “and”? If the most honest name for a function is <code>validateAndSaveAndNotifyUser</code>, the function is three functions pretending to be one. The naming test doesn’t lie — it’s a direct readout of the function’s responsibility. I’ve seen this test convince engineers who were unmoved by SOLID principles or Uncle Bob quotes, because it’s visceral: if you can’t say what the function does in a few words, you already know something is wrong.</p> </article> <article> <h1>Lesson 16: Barriers and Once — Synchronization primitives</h1> <p>Thu, 05 Dec 2024 10:15:00 +0000</p> <p>I was building a benchmark suite once — eight threads, each measuring throughput of a different operation. The problem was that threads started at different times depending on OS scheduling. Thread 0 might start 50ms before thread 7, skewing the results. I needed all threads to start their measurement at exactly the same time.</p> <p>That’s what barriers do. Everyone waits at the barrier until the last thread arrives, then they all proceed together.</p> </article> <article> <h1>Lesson 7: Golden File Testing — Store expected output, compare on run</h1> <p>Thu, 05 Dec 2024 00:00:00 +0000</p> <p>Some functions produce output that’s too large or too structured to assert inline. A template renderer, a code generator, a JSON serializer for a deeply nested type, a CLI help text formatter — any of these can produce hundreds of lines of output that you need to verify is correct. Hardcoding that expected output inside the test function creates a wall of string literals. The golden file pattern solves this by storing the expected output in a file, comparing against it at test time, and offering a flag to regenerate it when the output intentionally changes.</p> </article> <article> <h1>Lesson 15: Condvar — Waiting for conditions</h1> <p>Tue, 03 Dec 2024 14:40:00 +0000</p> <p>Early in my career, I wrote a producer-consumer queue using a mutex and a busy-wait loop. The consumer would lock the mutex, check if there’s data, unlock, sleep for 10 milliseconds, and repeat. It worked, but it burned CPU doing nothing and had up to 10ms of latency on every message. My tech lead pointed me to condition variables, and the latency dropped to microseconds while CPU usage went to near zero.</p> </article> <article> <h1>Lesson 6: Password Hashing — bcrypt or argon2, nothing else</h1> <p>Mon, 02 Dec 2024 00:00:00 +0000</p> <p>Password hashing is one of those topics where the correct answer is short and clear, the wrong answers are numerous and subtle, and developers who confidently implement one of the wrong answers often do not know they did anything wrong until a database is leaked and journalists start writing about it. I have sat in a post-mortem where the words “we were using MD5” were spoken in a conference room full of very quiet people. That was not my code, but I understood how it happened — MD5 was the “hash function” the developer knew, and they did not realize it was entirely unsuitable for passwords.</p> </article> <article> <h1>Lesson 14: parking_lot — Faster mutexes</h1> <p>Sun, 01 Dec 2024 09:25:00 +0000</p> <p>I switched a high-contention service from <code>std::sync::Mutex</code> to <code>parking_lot::Mutex</code> and saw lock acquisition time drop by 30% under load. The API is nearly identical — it was a find-and-replace job. That’s the kind of optimization I like: massive payoff, zero complexity cost.</p> <p><code>parking_lot</code> is one of those crates that probably should have been in the standard library. It provides the same synchronization primitives as std, but faster, smaller, and with more features.</p> </article> <article> <h1>Lesson 5: Profiling in Production — pprof is not just for development</h1> <p>Sun, 01 Dec 2024 00:00:00 +0000</p> <p>I used to think profiling was something you did when you had a performance problem: reproduce it locally, run pprof, stare at the flame graph, fix the hot path. A fire-fighting tool, not an always-on system.</p> <p>Then we had a memory leak in production that we couldn’t reproduce locally. The heap grew by about 50 MB per hour under real traffic patterns, causing an OOM every eight hours and a rolling restart across the fleet. Our staging environment used synthetic load that didn’t trigger the leak. We had no profile data from when the leak was building — only from after the crash, when the heap had already been cleared.</p> </article> <article> <h1>Lesson 13: Fan-Out Fan-In in Rust — Parallel pipelines</h1> <p>Fri, 29 Nov 2024 12:50:00 +0000</p> <p>One of the most satisfying architectures I’ve built was a real-time analytics pipeline. Events came in through a single ingestion point, fanned out to eight processing workers, then fanned back in to a single aggregator that wrote results to the database. Throughput went from 2,000 events/second to 14,000 with zero data loss.</p> <p>Fan-out/fan-in is one of those patterns that looks simple on a whiteboard but has real subtlety in implementation. Getting the channel lifecycle right, handling errors, managing backpressure — that’s where things get interesting.</p> </article> <article> <h1>Lesson 4: Building a Serializer — encoding/json under the hood</h1> <p>Thu, 28 Nov 2024 00:00:00 +0000</p> <p><code>encoding/json</code> is Go’s most-used package and one of its most instructive implementations. Under the hood it is almost entirely reflection: it inspects struct field types, reads <code>json</code> tags, handles pointer dereferences, recurses into nested structs, and handles special cases like <code>time.Time</code> and <code>json.Marshaler</code> interface implementations. Building a simplified version of a struct serializer from scratch is the best way to understand both how reflection works in practice and why <code>encoding/json</code> makes the design choices it does.</p> </article> <article> <h1>Lesson 12: Worker Pool Patterns — Bounded concurrency</h1> <p>Wed, 27 Nov 2024 08:35:00 +0000</p> <p>I blew up a production database once by spawning unlimited concurrent connections. A batch job that normally processed 100 items suddenly got 50,000. Each item opened a database connection. The connection pool maxed out, then the OS ran out of file descriptors. The database server stopped accepting connections from any service. All because I wrote <code>for item in items { thread::spawn(...) }</code> without thinking about bounds.</p> <p>Worker pools solve this. Fixed number of threads, bounded queue, backpressure when the system is overloaded. After that incident, I never write unbounded concurrency again.</p> </article> <article> <h1>Lesson 11: Crossbeam — Scoped threads and lock-free structures</h1> <p>Mon, 25 Nov 2024 11:05:00 +0000</p> <p>Before Rust 1.63 added <code>thread::scope</code> to the standard library, crossbeam was the only ergonomic way to spawn threads that could borrow local data. Even now that std has scoped threads, crossbeam remains essential. Its channels are faster than <code>std::sync::mpsc</code>, it provides lock-free data structures, and its utilities fill gaps the standard library doesn’t cover.</p> <p>I reach for crossbeam in nearly every concurrent Rust project. Here’s why.</p> <h2 id="crossbeam-channels">Crossbeam Channels</h2> <p>The biggest win: crossbeam’s channels are multi-producer, multi-consumer (MPMC) and significantly faster than <code>std::sync::mpsc</code>.</p> </article> <article> <h1>Lesson 10: Math Patterns — When the Answer Is Math, Not Code</h1> <p>Mon, 25 Nov 2024 00:00:00 +0000</p> <p>Some interview problems look like they need a data structure or a clever algorithm, but the answer is actually just math. I’ve watched candidates build hash maps and simulate processes for problems that have elegant O(1) or O(log n) solutions grounded in number theory or geometric reasoning. When I encountered Happy Number for the first time, I tried to detect cycles with a hash set — which works, but the Floyd’s cycle detection approach (same one as linked list cycle detection) is what separates a good answer from a great one.</p> </article> <article> <h1>Lesson 3: CQRS + Event Sourcing Together — When the combination makes sense</h1> <p>Sun, 24 Nov 2024 00:00:00 +0000</p> <p>CQRS and event sourcing are often discussed together, presented as a single package, and that conflation is responsible for a lot of unnecessary complexity in codebases that should have stayed simple. I’ve seen teams adopt both because they read a blog post, without being clear on why they needed either. I’ve also seen teams who should have used both and instead built elaborate workarounds that were essentially CQRS and event sourcing with worse ergonomics. The question isn’t “should I use CQRS and event sourcing?” — it’s “do I have the specific problems these patterns solve?”</p> </article> <article> <h1>Lesson 10: Rayon — Data parallelism made easy</h1> <p>Sat, 23 Nov 2024 15:20:00 +0000</p> <p>I had a batch processing job — reading 50,000 JSON files, parsing them, running validation, writing results. Single-threaded, it took 12 minutes. I added Rayon, changed <code>.iter()</code> to <code>.par_iter()</code>, and it dropped to 90 seconds. Five characters added to my code. That’s it.</p> <p>Rayon is probably the most impressive crate in the Rust ecosystem for the effort-to-impact ratio. If you have CPU-bound work that operates on collections, Rayon makes parallelism trivial.</p> </article> <article> <h1>Lesson 5: Ignoring Context — The cancellation nobody checked</h1> <p>Fri, 22 Nov 2024 00:00:00 +0000</p> <p>I spent a Tuesday afternoon tracking down why our service continued doing expensive database work after clients had long since disconnected. An HTTP client with a 3-second timeout would cancel the request, but our handler would still run three downstream database queries that together took 8 seconds. The handler was checking for errors but never checking the context. By the time it finished, the client had retried twice, and we were now running three copies of the same 8-second work simultaneously.</p> </article> <article> <h1>Lesson 9: Send and Sync — The traits behind thread safety</h1> <p>Thu, 21 Nov 2024 09:40:00 +0000</p> <p>There’s a moment in every Rust developer’s life when they try to send an <code>Rc<RefCell<Vec<String>>></code> to another thread and get a wall of compiler errors. They Google the error, see something about <code>Send</code> and <code>Sync</code>, patch the type to <code>Arc<Mutex<Vec<String>>></code>, and move on without understanding why.</p> <p>I did exactly that for six months. Then I needed to write a custom type that crossed thread boundaries, and I had to actually learn what these traits mean. Turns out they’re beautifully simple once you see the design.</p> </article> <article> <h1>Lesson 2: gRPC-Based Plugin Architecture — How Terraform and Vault do plugins</h1> <p>Thu, 21 Nov 2024 00:00:00 +0000</p> <p>After I understood how <code>hashicorp/go-plugin</code> worked with net/rpc, the next question was obvious: how does Terraform manage hundreds of community-contributed providers, written by different teams, evolving on different schedules, sometimes in languages other than Go? The answer is gRPC. Terraform’s provider protocol is a protobuf schema, communicated over the same subprocess-plus-RPC architecture from Lesson 1 — but with gRPC instead of net/rpc. That substitution buys you schema evolution, multi-language support, streaming, and a strongly-typed IDL. This lesson shows you how to build a plugin system using that pattern.</p> </article> <article> <h1>Lesson 5: Message Queues in Go — NATS, RabbitMQ, Kafka — pick your tradeoff</h1> <p>Wed, 20 Nov 2024 00:00:00 +0000</p> <p>I’ve integrated all three of these systems in production Go services, and the question I get most often is: “Which one should I use?” The honest answer is that it depends on what guarantee you actually need — and most engineers pick based on familiarity or hype rather than requirements. NATS, RabbitMQ, and Kafka solve meaningfully different problems, and choosing the wrong one creates operational pain that no amount of clever application code can fix.</p> </article> <article> <h1>Lesson 8: Memory Ordering — Relaxed, Acquire, Release, SeqCst</h1> <p>Tue, 19 Nov 2024 13:15:00 +0000</p> <p>Memory ordering is the thing that separates people who <em>use</em> concurrent code from people who <em>write</em> concurrent primitives. I avoided understanding it for years, using <code>SeqCst</code> everywhere like a safety blanket. It worked. But it left performance on the table and, more importantly, left me unable to read half the lock-free code I encountered.</p> <p>So here’s the actual explanation — no hand-waving.</p> <h2 id="why-ordering-matters">Why Ordering Matters</h2> <p>Modern CPUs and compilers reorder instructions for performance. Your code says “write A, then write B,” but the CPU might execute B first if there’s no dependency between them. On a single thread, this is invisible — the final result is the same.</p> </article> <article> <h1>Lesson 15: CAP Theorem in Practice — What It Actually Means for Your System</h1> <p>Tue, 19 Nov 2024 00:00:00 +0000</p> <p>CAP theorem is probably the most cited and most misunderstood concept in distributed systems interviews. Candidates memorize “you can only pick two of consistency, availability, and partition tolerance” and then either over-apply it (treating every design decision as a CAP trade-off) or under-apply it (never relating it to actual design choices). The theorem is real and important, but the way it’s usually taught in 30-second summaries strips out the nuance that makes it actually useful. This final lesson clears that up.</p> </article> <article> <h1>Lesson 4: time Package Gotchas — Timezones, monotonic clocks, and the bug in your cron</h1> <p>Mon, 18 Nov 2024 00:00:00 +0000</p> <p>The <code>time</code> package looks straightforward right up until the moment a bug report arrives saying “the nightly job didn’t run last Sunday.” It never runs on the Sunday when daylight saving time ends. Because that Sunday has 25 hours, and the cron expression fires twice at the ambiguous time, and the second firing is skipped because the code thinks it already ran. I’ve debugged this exact bug, and the root cause is always the same: someone — usually me — assumed time is simpler than it is.</p> </article> <article> <h1>Lesson 7: Atomics — Lock-free primitives</h1> <p>Sun, 17 Nov 2024 07:45:00 +0000</p> <p>I once replaced a <code>Mutex<u64></code> counter in a hot path with an <code>AtomicU64</code> and saw throughput jump 40%. Not because mutexes are slow — they’re fast. But for a single integer being incremented by 32 threads, the overhead of acquiring and releasing a lock millions of times per second adds up to real time.</p> <p>Atomics are the foundation of lock-free programming. They let you do thread-safe operations on primitive values without any lock at all.</p> </article> <article> <h1>Lesson 8: When Duplication Is Better Than Abstraction — Bad abstraction costs more than repeated code</h1> <p>Sun, 17 Nov 2024 00:00:00 +0000</p> <p>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: <strong>duplication is a problem you can see. Bad abstraction is a problem you can’t see until it’s too late.</strong></p> <p>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.</p> </article> <article> <h1>Lesson 6: Arc<Mutex<T>> — The shared mutable state pattern</h1> <p>Fri, 15 Nov 2024 10:30:00 +0000</p> <p>I remember staring at <code>Arc<Mutex<HashMap<String, Vec<u8>>>></code> in a codebase and thinking “this is the ugliest type I’ve ever seen.” Three months later, after debugging a similar system in Go that had zero type safety around its concurrent map access, I came crawling back to Rust’s ugly-but-correct approach.</p> <p>The <code>Arc<Mutex<T>></code> pattern is everywhere in Rust concurrent code. Understanding <em>why</em> it exists — not just how to type it — is the key.</p> </article> <article> <h1>Lesson 5: GC Behavior and Tuning — GOGC and GOMEMLIMIT changed the game</h1> <p>Fri, 15 Nov 2024 00:00:00 +0000</p> <p>For years, tuning Go’s GC meant tweaking <code>GOGC</code> and hoping for the best. I operated on vibes and guesswork. Then Go 1.19 introduced <code>GOMEMLIMIT</code> — a hard memory limit that fundamentally changed how I reason about GC tuning. Suddenly I had a second axis of control that actually matched how production memory is constrained. This lesson is the mental model I wish I had from day one.</p> <h2 id="the-problem">The Problem</h2> <p>Go uses a concurrent, tri-color mark-and-sweep garbage collector. “Concurrent” means most of the GC work happens while your program is running, not in stop-the-world pauses. This is generally excellent, but the GC needs to be triggered somehow, and the default trigger can be surprising.</p> </article> <article> <h1>Lesson 5: Design Twitter/X — Tweet fanout, timeline ranking, trending topics at 500M users</h1> <p>Thu, 14 Nov 2024 00:00:00 +0000</p> <p>Twitter is the classic system design problem for good reason. It looks like a glorified blog until you start pulling on the threads: how does a tweet from a user with 100 million followers appear in every follower’s timeline within seconds? How do you rank timelines without reading millions of tweets per request? How do you identify trending topics across 500 million users in near real-time? Each of these is a genuinely hard problem, and they interact in non-obvious ways.</p> </article> <article> <h1>Lesson 5: Shared State — Mutex, RwLock, and poisoning</h1> <p>Wed, 13 Nov 2024 16:55:00 +0000</p> <p>The nastiest production bug I ever tracked down involved a Java ConcurrentHashMap that was “thread-safe” in the API sense but not in the logic sense. Two threads would read a key, both see it’s absent, both insert with computed values, and one would silently overwrite the other. The map itself was fine — the <em>access pattern</em> was broken.</p> <p>Rust’s Mutex won’t save you from logic bugs either. But it will absolutely prevent you from forgetting the lock in the first place.</p> </article> <article> <h1>Lesson 5: Composition with Embedding — Small interfaces compose into powerful contracts</h1> <p>Tue, 12 Nov 2024 00:00:00 +0000</p> <p>One of the things that surprised me most about Go when I came from Python was that Go has no inheritance. No base classes, no method overriding, no type hierarchies. What it has instead is embedding — the ability to include one type inside another so that the outer type promotes the inner type’s methods. Combined with interface composition, this gives you something more flexible than inheritance: you can build complex behaviors from simple, testable pieces without the fragility that comes from deep class trees.</p> </article> <article> <h1>Lesson 4: Channels — mpsc and beyond</h1> <p>Mon, 11 Nov 2024 09:10:00 +0000</p> <p>The first concurrent system I built that actually worked well was a log aggregation pipeline. Multiple producers writing log lines, one consumer batching and flushing to disk. No shared state, no locks, no races. Just messages flowing through a pipe.</p> <p>That experience sold me on message passing. And Rust’s channel implementation makes it surprisingly ergonomic.</p> <h2 id="the-problem-shared-state-is-hard">The Problem: Shared State Is Hard</h2> <p>You <em>can</em> share state between threads with mutexes. But every shared mutable variable is a coordination point, a potential bottleneck, and a source of bugs. The more threads touching the same data, the harder the code is to reason about.</p> </article> <article> <h1>Lesson 10: Redis, MongoDB, and Non-Relational Stores — Beyond SQL</h1> <p>Sun, 10 Nov 2024 15:37:00 +0000</p> <p>I spent a week optimizing a Postgres query that powered a leaderboard. It involved a complex window function over millions of rows, and no amount of indexing got it under 200ms. Then a senior engineer walked over, looked at the query, and said “Why isn’t this in Redis?” He was right. I replaced 30 lines of SQL with a sorted set and the response time dropped to 2ms.</p> <p>Not every data problem is a SQL problem. Sometimes you need the right tool, not a better query plan.</p> </article> <article> <h1>Lesson 5: Benchmarking Done Right — testing.B is not what you think</h1> <p>Sun, 10 Nov 2024 00:00:00 +0000</p> <p>Writing a Go benchmark feels simple. You drop <code>Benchmark</code> in front of a function name, loop from 0 to <code>b.N</code>, run <code>go test -bench=.</code>, and get a number. The number feels authoritative. I spent about a year trusting benchmark numbers that were wrong — not wrong because of bugs, but wrong because of how the benchmark was written. The Go benchmark framework is excellent, but it has sharp edges that will mislead you until you learn to see them.</p> </article> <article> <h1>Lesson 3: move Closures — Sending data to threads</h1> <p>Sat, 09 Nov 2024 14:20:00 +0000</p> <p>When I first started writing threaded Rust code, I hit the same compiler error about forty times in one afternoon. Something about closures borrowing values that might be dropped. I kept slapping <code>move</code> on closures until things compiled, without really understanding what was happening.</p> <p>That’s a terrible way to learn. So here’s the actual explanation I wish I’d had.</p> <h2 id="the-problem-closures-and-thread-lifetimes">The Problem: Closures and Thread Lifetimes</h2> <p>When you pass a closure to <code>thread::spawn</code>, the new thread might run for an arbitrary amount of time. It could outlive the function that spawned it. It could outlive the variables it references.</p> </article> <article> <h1>Lesson 3: Your Story — Connecting your career narrative to the role</h1> <p>Sat, 09 Nov 2024 00:00:00 +0000</p> <p>Almost every interview starts the same way: “So, tell me about yourself.” And almost every engineer I’ve talked to hates this question. Not because they don’t know themselves, but because it feels formless. You could say anything. You could say everything. What are they actually asking?</p> <p>What they’re asking is: give me a thesis statement for why you’re sitting in this chair. Not a resume recitation. Not a biography. A thread that connects where you’ve been to why this job is the logical next step. That thread is your career narrative.</p> </article> <article> <h1>Lesson 5: Monolith vs Multi-Module — One go.mod or many? It depends.</h1> <p>Fri, 08 Nov 2024 00:00:00 +0000</p> <p>When I first started structuring larger Go projects, I defaulted to what felt natural: one repository, one <code>go.mod</code>. It worked for a long time. Then I joined a project with four services in a single repo, each with different dependency requirements, and suddenly the single <code>go.mod</code> was pulling in every dependency of every service for every build. Tests for the email service were slow because the <code>go test</code> run was loading the ML inference library needed only by the recommendation service. That was when I started thinking seriously about module boundaries, not just package boundaries.</p> </article> <article> <h1>Lesson 2: std::thread — Spawning and joining</h1> <p>Thu, 07 Nov 2024 11:45:00 +0000</p> <p>A few years back I was reviewing a Go service that spawned goroutines like confetti at a parade — hundreds of them, no tracking, no lifecycle management. When the service shut down, half those goroutines just vanished mid-work. Orphaned database connections everywhere. The Go runtime made it <em>so easy</em> to fire off concurrent work that nobody stopped to think about cleanup.</p> <p>Rust’s threading model forces you to think about it. Every thread gives you a handle. Every handle demands acknowledgment. You can ignore it — but you have to do so explicitly.</p> </article> <article> <h1>Lesson 9: Bit Manipulation — The Trick Questions That Test Fundamentals</h1> <p>Thu, 07 Nov 2024 00:00:00 +0000</p> <p>Bit manipulation problems have a reputation for being tricks — the kind of problem where you either know the one-liner or you don’t, and if you don’t, no amount of reasoning will get you there. That’s mostly false. The problems in this lesson have elegant solutions, but those solutions come from understanding a small set of bitwise properties and applying them deliberately. I’ve seen candidates ace these problems in interviews not because they memorized the answer, but because they reasoned through the bit properties in real time.</p> </article> <article> <h1>Lesson 9: N+1 Queries, Indexes, and EXPLAIN — Database performance in Rust</h1> <p>Wed, 06 Nov 2024 07:52:00 +0000</p> <p>A coworker asked me to look at an endpoint that was taking 8 seconds to return 50 orders. The table had 200K rows — not big by any standard. I opened the code, and the pattern was immediately obvious: fetch 50 orders, then for each order, fetch its items in a separate query. Fifty-one database round trips where one would do.</p> <p>The N+1 query problem is the most common performance mistake in database-backed applications, and Rust doesn’t magically prevent it. You need to know what to look for.</p> </article> <article> <h1>Lesson 3: Service Discovery — Finding services without hardcoding URLs</h1> <p>Wed, 06 Nov 2024 00:00:00 +0000</p> <p>When I first started building Go microservices, every service had a config file with a list of URLs. <code>order-service-url: http://10.0.1.42:8080</code>. That worked fine until the service moved, scaled out, or the IP changed during a deployment. Then the deployment would fail, someone would update the config, redeploy, and we’d write a Jira ticket to “fix the discovery mechanism eventually.” Service discovery is that fix — it’s how services find each other without hardcoding network locations.</p> </article> <article> <h1>Lesson 1: Why Rust Concurrency Is "Fearless" — The compiler has your back</h1> <p>Tue, 05 Nov 2024 08:30:00 +0000</p> <p>I once spent three days chasing a race condition in a Java service that only manifested under production load. The bug? Two threads updating a shared HashMap — no synchronization, no errors at compile time, no warnings. Just silent data corruption that showed up as incorrect billing amounts. Three days of my life, gone, because the language didn’t care.</p> <p>Then I tried to write the same bug in Rust. The compiler said no.</p> </article> <article> <h1>Lesson 6: Mocking Alternatives — Interfaces over mocks, always</h1> <p>Tue, 05 Nov 2024 00:00:00 +0000</p> <p>Mocking has a bad reputation in the Go community, and some of it is deserved. Not because mocks are inherently wrong, but because the way most people use them — generating verbose stubs from interfaces, asserting on call counts, verifying argument order — produces tests that are coupled to implementation details rather than behaviour. Refactor the internals of a function without changing its public contract, and suddenly half your mocks break. That’s not a test problem. That’s a mock-as-test-double problem.</p> </article> <article> <h1>Lesson 14: Designing for Failure — Circuit Breakers, Bulkheads, Chaos</h1> <p>Mon, 04 Nov 2024 00:00:00 +0000</p> <p>In distributed systems, failure is not an exceptional case — it’s the default condition. Networks partition. Hard drives fail. Memory fills up. Dependencies have bugs. Every distributed system that’s been running for more than a few years has experienced every kind of failure you can imagine, and many you can’t. The engineers who build resilient systems aren’t smarter than the ones who don’t. They’ve just internalized a single principle: design for when things go wrong, not for when things go right.</p> </article> <article> <h1>Lesson 8: Testing with Real Databases — No more mocking SQL</h1> <p>Sun, 03 Nov 2024 13:15:00 +0000</p> <p>I spent two days debugging a production issue where a query returned duplicate rows. The unit tests all passed — every mock returned exactly the expected data. The problem was a missing <code>DISTINCT</code> in a JOIN query that only manifested with real data containing multiple matching rows. The mocks were too perfect. They never produced the messy data that real databases contain.</p> <p>That was when I stopped mocking SQL.</p> <h2 id="the-problem-with-mocking-database-calls">The Problem with Mocking Database Calls</h2> <p>Mocking databases is popular because it’s convenient. You don’t need Docker, you don’t need a test database, your tests run in milliseconds. But you’re testing the wrong thing.</p> </article> <article> <h1>Lesson 4: Config Injection — Environment variables, flags, files — in that order</h1> <p>Sat, 02 Nov 2024 00:00:00 +0000</p> <p>Configuration management is one of those topics that seems solved until you maintain a service that runs in four different environments, has twenty configurable parameters, and needs its secrets rotated without a redeployment. I’ve gone through several evolutionary stages on this: hardcoded values (the naive phase), a single <code>config.yaml</code> file, then twelve <code>config-{env}.yaml</code> files, and finally landing on what the 12-factor app methodology describes — environment variables as the source of truth for deployment-specific configuration.</p> </article> <article> <h1>Lesson 7: Building Type-Safe Query Builders — Queries that can't be wrong</h1> <p>Fri, 01 Nov 2024 09:28:00 +0000</p> <p>I was reviewing a PR that had a search endpoint with 12 optional filters. The handler was a 200-line function full of <code>if let Some(...)</code> blocks, each appending a different SQL fragment to a <code>String</code>. It worked — until someone forgot a space between <code>AND</code> and a column name, and the query silently returned zero results instead of erroring. No compile error. No test failure. Just a missing space in a string.</p> </article> <article> <h1>Lesson 14: Randomized Algorithms — Reservoir sampling, HyperLogLog, probabilistic counting</h1> <p>Fri, 01 Nov 2024 00:00:00 +0000</p> <p>There is a class of production problems where exact answers are either impossible or not worth the cost. You want to know approximately how many unique visitors hit your site today. You want to sample 1% of requests for tracing without reading every request into memory first. You want to check if a username is already taken without querying the database on every keystroke.</p> <p>Randomized algorithms provide exact answers with known probability bounds, or approximate answers with bounded error, using a fraction of the memory or time that exact computation would require. I was skeptical of “probabilistic” algorithms for a long time — it seemed like trading correctness for efficiency. Then I learned what the error bounds actually are. A HyperLogLog cardinality estimate with 1.5% error using 12KB of memory is a better engineering choice than a perfect count using 100MB, for the vast majority of use cases.</p> </article> <article> <h1>Lesson 6: The Repository Pattern in Rust — Abstracting persistence</h1> <p>Wed, 30 Oct 2024 16:40:00 +0000</p> <p>I once inherited a codebase where every HTTP handler had raw SQL queries inline — <code>sqlx::query!</code> calls scattered through 80+ route handlers. Changing a table name meant grep-and-replace across the entire project. Adding a cache layer meant touching every handler. Testing a handler meant spinning up a real database. It worked, technically, but nobody wanted to touch it.</p> <p>The repository pattern fixes this. It puts a wall between your business logic and your database, and that wall pays for itself fast.</p> </article> <article> <h1>Lesson 4: Signal Handling — Catch SIGTERM or lose your work</h1> <p>Wed, 30 Oct 2024 00:00:00 +0000</p> <p>Most CLI tools work perfectly on the happy path and fail silently on the unhappy one. The user presses Ctrl-C, the OS sends SIGINT, and the process dies immediately — leaving a temp file half-written, a database connection open, or a progress bar frozen mid-operation. The problem is invisible because most of the time nobody looks at what gets left behind. Until a deployment script depends on that temp file being complete, or a database hits its connection limit, or a batch job loses six hours of progress because the container was terminated between checkpoints.</p> </article> <article> <h1>Lesson 5: Transactions and Error Rollback — Atomic operations</h1> <p>Mon, 28 Oct 2024 10:05:00 +0000</p> <p>A payment service I worked on had a subtle bug: it deducted money from the user’s wallet, then tried to create an order record. If the order insert failed — constraint violation, timeout, anything — the money was already gone. The user’s balance was decremented but they had no order. We called these “ghost charges” internally, and customers called them something less polite.</p> <p>The fix was embarrassingly simple: wrap both operations in a transaction.</p> </article> <article> <h1>Lesson 12: Production Deployment — Docker, graceful shutdown, observability</h1> <p>Mon, 28 Oct 2024 08:55:00 +0000</p> <p>Shipping to production is where the real education begins. Your local dev environment is a controlled fantasy — one instance, no load balancer, fast database on localhost, unlimited memory. Production is a hostile environment where your service gets killed mid-request, runs out of memory at 3am, and needs to tell you what went wrong without you SSH-ing into a container. This lesson is about surviving out there.</p> <h2 id="dockerfile-the-multi-stage-build">Dockerfile: The Multi-Stage Build</h2> <p>Rust binaries are statically linked (or nearly so). A compiled Rust service can run in a scratch or distroless container with no runtime dependencies. This means tiny images — often under 20MB.</p> </article> <article> <h1>Lesson 5: Pagination Done Right — Offset pagination breaks at scale</h1> <p>Mon, 28 Oct 2024 00:00:00 +0000</p> <p>I have shipped offset-based pagination more times than I would like to admit. It looks clean, it is trivially easy to implement, and it works perfectly — until the table reaches about 100,000 rows. Then it starts to slow down, and by a million rows it is actively harmful. I had a support dashboard that froze every time someone clicked to page 47. That was the moment I stopped using <code>OFFSET</code>.</p> </article> <article> <h1>Lesson 4: Schema Migrations in Rust Projects — Evolving your database</h1> <p>Sat, 26 Oct 2024 19:12:00 +0000</p> <p>A teammate once ran <code>ALTER TABLE orders DROP COLUMN status</code> on the production database because he’d tested it locally and “it worked fine.” What he didn’t realize was that three other services depended on that column, and they all started throwing errors simultaneously. We spent the evening restoring from a backup.</p> <p>Schema migrations exist to prevent exactly this — they’re version control for your database.</p> <h2 id="the-problem">The Problem</h2> <p>Your database schema isn’t static. Features get added, requirements change, data models evolve. You need a way to:</p> </article> <article> <h1>Lesson 7: Refactoring Concrete to Generic — Start concrete, extract when proven</h1> <p>Fri, 25 Oct 2024 00:00:00 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 11: Integration Testing HTTP Services — Testing without mocks</h1> <p>Thu, 24 Oct 2024 15:40:00 +0000</p> <p>I worked on a codebase that had 600 unit tests with mocked HTTP clients, mocked databases, mocked everything. All 600 passed. The application didn’t work. The mocks were wrong — they returned data in a format the real database never produced. Those 600 tests gave the team confidence to ship broken code. Integration tests that hit real infrastructure are harder to write but they tell you whether your application actually works.</p> </article> <article> <h1>Lesson 3: Connection Pooling with deadpool and bb8 — Managing database connections</h1> <p>Thu, 24 Oct 2024 14:35:00 +0000</p> <p>I once watched a Rust service fall over under modest load — maybe 200 concurrent requests — because every request opened a new Postgres connection, used it for one query, and dropped it. The database was spending more time on TLS handshakes and connection setup than on actual queries. CPU was fine, memory was fine, but <code>pg_stat_activity</code> showed 200+ connections churning constantly. The fix took ten lines of code: add a connection pool.</p> </article> <article> <h1>Lesson 2: CGo Performance and Pitfalls — The hidden cost of crossing the boundary</h1> <p>Thu, 24 Oct 2024 00:00:00 +0000</p> <p>When I profiled a service that was spending 40% of its time in cgo calls, I thought I was measuring the C library. I was not. I was measuring the overhead of <em>getting to</em> the C library. The actual C work was fast. What was slow was the goroutine-to-OS-thread transition, the stack switching, and the runtime bookkeeping that happens every single time Go code crosses the C boundary. Understanding this overhead is what separates cgo code that runs fine from cgo code that becomes a bottleneck.</p> </article> <article> <h1>Lesson 2: Diesel — The ORM approach</h1> <p>Tue, 22 Oct 2024 08:47:00 +0000</p> <p>I was two weeks into a project where I had to write about 40 CRUD endpoints for an admin panel. Each one needed the same pattern: validate input, build a query, map results to a struct, handle errors. By endpoint number six, I was copy-pasting SQLx queries and changing column names. That’s when a colleague asked, “Why aren’t you using Diesel?”</p> <p>He was right. Sometimes you don’t want to write SQL. Sometimes you want the boilerplate to disappear.</p> </article> <article> <h1>Lesson 5: Auth Middleware — Authentication is not authorization</h1> <p>Tue, 22 Oct 2024 00:00:00 +0000</p> <p>A few years ago I audited a Go API where every endpoint was protected by an authentication middleware. The middleware checked for a valid JWT, extracted the user ID, and set it in the request context. The developer was proud of it — every route was secured. The problem was that the product had a concept of “organizations” — users belonged to organizations — and the API let you fetch any organization’s data as long as you were authenticated. The authentication was solid. The authorization was completely absent.</p> </article> <article> <h1>Lesson 10: OpenAPI / Swagger Generation — Documentation from code</h1> <p>Mon, 21 Oct 2024 10:05:00 +0000</p> <p>I’ve never seen a team maintain a separate OpenAPI spec in sync with their actual API for more than three months. Someone adds a field, forgets to update the docs, and suddenly the spec says one thing and the API does another. The only API documentation that stays accurate is documentation generated from the code itself. If the code changes, the docs change. No human discipline required.</p> <h2 id="the-approach-utoipa">The Approach: utoipa</h2> <p><code>utoipa</code> is the go-to crate for generating OpenAPI specs from Rust code. It uses derive macros and attribute annotations to produce an OpenAPI 3.1 JSON spec at compile time. You add annotations to your types and handlers, and utoipa generates a spec that’s always in sync with your code.</p> </article> <article> <h1>Lesson 13: Design a Payment System — Idempotency, Reconciliation, Double-Entry</h1> <p>Mon, 21 Oct 2024 00:00:00 +0000</p> <p>Payment systems have a property that almost no other software has: the cost of a bug isn’t a bad user experience — it’s a legal liability and a business catastrophe. Charging a customer twice, losing a transfer in a network failure, or crediting the wrong account can result in millions of dollars of loss and destroyed trust. Every other system we’ve covered tolerates a degree of eventual inconsistency. Payment systems, in most cases, do not. This lesson is about building for that level of correctness.</p> </article> <article> <h1>Lesson 1: SQLx — Compile-time checked queries</h1> <p>Sun, 20 Oct 2024 11:23:00 +0000</p> <p>I shipped a typo in a SQL column name to production last year. The column was <code>user_nme</code> instead of <code>user_name</code>. The Go service compiled fine, the tests passed (they used mocks), and the bug sat in production for three hours before a customer reported it. Three hours of silent failures because the query returned zero rows instead of erroring out.</p> <p>That was the day I started using SQLx in Rust. I haven’t shipped a SQL typo since.</p> </article> <article> <h1>Lesson 4: Code Review Heuristics — What to look for in a Go PR</h1> <p>Sun, 20 Oct 2024 00:00:00 +0000</p> <p>A good code review is not a diff-reading exercise. It’s a transfer of understanding — the reviewer asks “do I understand what this code does, why it does it, and what it doesn’t do?” If the answer to any of those is no, that’s a comment, not a nitpick. I’ve done hundreds of Go reviews and the feedback I give clusters into the same ten or fifteen patterns so reliably that I eventually wrote them down as a checklist. This lesson is that checklist, with examples.</p> </article> <article> <h1>Lesson 9: Rate Limiting and Throttling — Protecting your service</h1> <p>Fri, 18 Oct 2024 13:10:00 +0000</p> <p>We launched a public API without rate limiting. Within a week, a single user was making 200 requests per second — not maliciously, just a badly written script with no backoff. Their traffic consumed 40% of our database connections and degraded performance for everyone else. We added rate limiting, their requests started getting 429s, they fixed their script, and everyone was happy. Should’ve been there from day one.</p> <h2 id="why-rate-limit">Why Rate Limit</h2> <p>Three reasons, in order of importance:</p> </article> <article> <h1>Lesson 4: Correlation IDs — Connect the logs to the trace to the user</h1> <p>Fri, 18 Oct 2024 00:00:00 +0000</p> <p>A support ticket lands: “User 8842 says their order failed at 2:47 PM yesterday.” You open your log aggregator. You search for <code>user_id = 8842</code>. You get 4,000 log lines — the user made 80 requests that afternoon. You filter to the 2:43–2:51 PM window. You get 300 lines. They interleave with log lines from 12 concurrent requests from other users because your log output is not partitioned by request. The error message, when you find it, says <code>internal server error</code>. No stack trace, no underlying cause, no request that produced it.</p> </article> <article> <h1>Lesson 13: Cryptographic Primitives — Hashing, HMAC, and never rolling your own</h1> <p>Thu, 17 Oct 2024 00:00:00 +0000</p> <p>There is a joke in security circles: every developer thinks they can write their own crypto. The punchline is that everyone who has tried has been wrong. Cryptography is the one area of computer science where being 99% correct is the same as being completely wrong. A subtle timing vulnerability, a nonce reuse, or a hash function with the wrong properties can completely destroy a security guarantee that looks solid on paper.</p> </article> <article> <h1>Lesson 8: WebSockets with Axum — Real-time in Rust</h1> <p>Wed, 16 Oct 2024 09:20:00 +0000</p> <p>A startup I consulted for was polling their REST API every 500 milliseconds to check for new messages. Forty thousand clients, each making two requests per second. That’s 80,000 requests per second to check if anything changed — and 99% of the time, nothing had. They switched to WebSockets, dropped their server count from 12 to 2, and their AWS bill fell by 70%. Polling is fine for dashboards that refresh every 30 seconds. For anything real-time, you want WebSockets.</p> </article> <article> <h1>Lesson 3: ConfigMaps and Secrets — Configuration without rebuilding</h1> <p>Wed, 16 Oct 2024 00:00:00 +0000</p> <p>We had a bug where the same Docker image was running in staging and production but behaving differently. I spent an hour diffing the code before I checked the environment variables. The staging pod had <code>CACHE_TTL=60</code> and the production pod had <code>CACHE_TTL=3600</code>. The image was identical. The behavior was totally different. That kind of environment-specific configuration — the values that shouldn’t be baked into the image — is exactly what ConfigMaps and Secrets are for. But they have subtleties that bite you if you treat them as simple key-value stores.</p> </article> <article> <h1>Lesson 4: Channel Misuse — You used a channel where a mutex would do</h1> <p>Tue, 15 Oct 2024 00:00:00 +0000</p> <p>Go’s channels are genuinely great. They make certain concurrent programming patterns — pipelines, fan-out, fan-in, worker pools — natural and readable. Because they are idiomatic and distinctly Go-like, there is a tendency among Go developers to reach for them first whenever concurrency is involved. The result is code that uses channels to protect shared state, which is what mutexes are for, or code that passes one value through a channel with ceremony that could be replaced by a function call.</p> </article> <article> <h1>Lesson 7: Pagination, Filtering, and Sorting — API patterns that scale</h1> <p>Mon, 14 Oct 2024 16:30:00 +0000</p> <p>We shipped a “list all orders” endpoint that returned everything. No pagination. Worked great in development with 50 test records. In production, one customer had 340,000 orders. The endpoint took 12 seconds, the response was 45MB, and the frontend crashed trying to render it. We added pagination that afternoon. You should add it before that afternoon.</p> <h2 id="offset-based-pagination">Offset-Based Pagination</h2> <p>The most common approach. Simple to implement, easy to understand, and good enough for most internal tools and admin panels.</p> </article> <article> <h1>Lesson 3: Model Serving — Latency, batching, A/B testing in production</h1> <p>Mon, 14 Oct 2024 00:00:00 +0000</p> <p>Training a model is satisfying. Deploying it to serve real traffic is humbling. I remember the first time I pushed a model to production and watched the p99 latency hover at 800ms on what was supposed to be a “fast” model. The benchmark had shown 12ms inference time. What happened? The benchmark ran the model on pre-loaded batches; production served one request at a time, loaded the model fresh on cold starts, and had no GPU batching. The gap between “the model is accurate” and “the model is fast enough to be useful” is where model serving engineering lives.</p> </article> <article> <h1>Lesson 3: Loop Variable Fix — The Go 1.22 change that fixed a decade of bugs</h1> <p>Sun, 13 Oct 2024 00:00:00 +0000</p> <p>If you have written Go for more than a few weeks, you have hit this bug. Or you have reviewed code that had it and caught it. Or — if you were unlucky — you shipped it to production and spent an hour staring at a data race report wondering what on earth was happening. The loop variable capture bug was so common that it was essentially a Go rite of passage. Every Go tutorial mentioned it. Every linter had a rule for it. And for a decade, the answer was always “just copy the variable inside the loop.”</p> </article> <article> <h1>Lesson 6: Database Integration — SQLx and connection management</h1> <p>Sat, 12 Oct 2024 07:45:00 +0000</p> <p>My first Rust web service leaked database connections. I opened a new connection per request and forgot that Rust’s ownership system doesn’t magically manage TCP sockets. After about 200 concurrent users, PostgreSQL refused new connections and the whole service went down. Connection pooling isn’t optional — it’s the first thing you set up.</p> <h2 id="why-sqlx">Why SQLx</h2> <p>There are three main approaches to database access in Rust:</p> <ul> <li><strong>Diesel</strong> — A full ORM with a query builder. Generates SQL at compile time. Requires a build step that connects to your database. Strong opinions about schema management.</li> <li><strong>SeaORM</strong> — An async ORM inspired by ActiveRecord. Higher level, more magic. Good if you like ORMs.</li> <li><strong>SQLx</strong> — Not an ORM. You write SQL. SQLx compiles your SQL queries against a real database at compile time, verifying that your SQL is valid and your result types match the columns returned.</li> </ul> <p>I use SQLx because I like writing SQL and I don’t trust ORMs in production. ORMs generate queries you can’t see, and when they generate bad queries (and they will), debugging is miserable. With SQLx, the SQL is right there in your code, and the compiler verifies it’s correct.</p> </article> <article> <h1>Lesson 4: Connection Pooling — One connection per request is a performance bug</h1> <p>Sat, 12 Oct 2024 00:00:00 +0000</p> <p>The first time I benchmarked a Go service against a database, the numbers were embarrassing. Five hundred requests per second, each one taking 30 milliseconds to execute a trivially simple query. The query itself took 2 milliseconds on the database server. The other 28 milliseconds were TCP handshake plus TLS plus PostgreSQL authentication — repeated for every single request because I had no connection pool.</p> <p>Connection pooling is one of those topics that feels like an advanced optimization until you discover that nearly every database driver in Go already pools connections by default — you just have to configure the pool instead of leaving it at its default settings, which are almost always wrong for your workload.</p> </article> <article> <h1>Lesson 2: Server-Side WASM — WASI, edge computing, and the universal binary</h1> <p>Fri, 11 Oct 2024 00:00:00 +0000</p> <p>When most people talk about WebAssembly, they mean the browser. That’s where it started, that’s where the tutorials are, and that’s where most of the public discourse still lives. But the more interesting story for backend engineers is what happens when you take the same sandboxed, portable binary model and apply it on the server.</p> <p>Server-side WebAssembly — specifically WebAssembly with WASI (the WebAssembly System Interface) — is not a toy. Cloudflare Workers runs WASM. Fastly Compute runs WASM. Fermyon Spin is built on it. The pattern is spreading from edge providers into general-purpose infrastructure. Understanding it now puts you ahead of where most backend engineers are.</p> </article> <article> <h1>Lesson 5: Database Testing with Testcontainers — Mock the DB and you mock the truth</h1> <p>Thu, 10 Oct 2024 00:00:00 +0000</p> <p>I used to mock databases. I had a clean <code>Store</code> interface, a <code>MockStore</code> implementation for tests, and 100% coverage on my service layer. I felt good about it. Then we migrated from MySQL to PostgreSQL and discovered that a dozen subtle behaviours we’d been mocking around were wrong — <code>UPSERT</code> semantics, NULL handling in <code>GROUP BY</code>, timestamp precision, transaction isolation differences. The mock had been lying to us for months. Testcontainers fixed that.</p> </article> <article> <h1>Lesson 5: Authentication — JWT, sessions, OAuth</h1> <p>Wed, 09 Oct 2024 11:00:00 +0000</p> <p>I’ve reviewed auth implementations at four different companies. Three of them stored passwords in SHA-256 without salting. One stored them in <em>plain text</em> in a column called <code>password_encrypted</code> — because naming it “encrypted” apparently counted as security. Auth is the part of your application that bad actors actively try to break. Getting it wrong isn’t a bug, it’s a liability.</p> <h2 id="password-hashing-do-this-right-or-dont-do-it-at-all">Password Hashing: Do This Right or Don’t Do It At All</h2> <p>Before we talk about tokens or sessions, let’s nail password storage. The rules are simple and non-negotiable:</p> </article> <article> <h1>Lesson 8: Sorting in Interviews — Can You Do Better Than O(n log n)?</h1> <p>Wed, 09 Oct 2024 00:00:00 +0000</p> <p>Most candidates treat sorting as a black box — call <code>sort.Ints</code> and move on. That works until an interviewer says “can you do this without sorting?” or “implement this yourself” or “what’s the worst-case time?” At that point, not understanding sorting costs you the offer.</p> <p>I don’t mean you need to memorize every sorting algorithm. You need three things: understand merge sort well enough to implement it (divide-and-conquer is a pattern you’ll use in other contexts); know QuickSelect for kth-element problems (it’s O(n) average and comes up constantly); and know when sorting is all you need and when the comparison lower bound of O(n log n) is a limit you can break. This lesson teaches all three.</p> </article> <article> <h1>Lesson 10: Conversion Traits — From, Into, TryFrom, AsRef</h1> <p>Tue, 08 Oct 2024 15:30:00 +0000</p> <p>I used to litter my Rust code with <code>.to_string()</code>, <code>as</code>, and manual conversion functions everywhere. Then I learned the conversion traits properly and my APIs went from clunky to clean. These traits are the glue that makes Rust code feel ergonomic — and understanding when to implement each one is the difference between a library that’s pleasant to use and one that makes people curse your name.</p> <h2 id="from-and-into--infallible-conversion">From and Into — Infallible Conversion</h2> <p><code>From<T></code> defines how to create a type from another type. It can’t fail. If there’s any possibility of failure, you want <code>TryFrom</code> instead.</p> </article> <article> <h1>Lesson 3: Struct Tags — Metadata your compiler ignores but your framework reads</h1> <p>Tue, 08 Oct 2024 00:00:00 +0000</p> <p>Struct tags are one of Go’s most practically useful metaprogramming tools and one of its least formally documented features. The syntax is simple — a raw string literal after the field type in a struct — but the convention built on top of it powers nearly every serialization library, ORM, validator, and configuration loader in the ecosystem. Understanding how tags work at the reflection level demystifies why <code>encoding/json</code> knows to use <code>omitempty</code>, why <code>database/sql</code> scanners can map column names to struct fields, and how you can build your own tag-driven behavior.</p> </article> <article> <h1>Lesson 4: Request Validation and Error Responses — Clean input handling</h1> <p>Mon, 07 Oct 2024 19:15:00 +0000</p> <p>A junior engineer on my team once deployed an endpoint that accepted any string as an email address. Someone submitted “lol” as their email, the downstream email service threw a cryptic error, and our error tracking lit up with 500s for an hour. Input validation isn’t glamorous, but skipping it is how you get paged at dinner.</p> <h2 id="the-problem-with-default-error-responses">The Problem with Default Error Responses</h2> <p>Out of the box, Axum’s error responses are… not great. Send malformed JSON to a <code>Json<T></code> handler and you get back:</p> </article> <article> <h1>Lesson 12: Design a Search Engine — Inverted Index and Ranking</h1> <p>Mon, 07 Oct 2024 00:00:00 +0000</p> <p>Search is the feature that separates usable products from unusable ones at scale. When your application has thousands of documents, a sequential scan works. At millions, it doesn’t. The difference between a search box that works and one that times out is a data structure invented in the 1960s that every modern search engine still fundamentally relies on: the inverted index. Understanding how it works — and how to build a system around it — is what this lesson is about.</p> </article> <article> <h1>Lesson 2: LLM API Clients — Calling Claude, GPT, and Groq from Go</h1> <p>Sun, 06 Oct 2024 00:00:00 +0000</p> <p>Most Go developers approach LLM APIs the same way they approach any REST API — write an HTTP client, handle errors, parse JSON. That instinct is correct, but LLM APIs have a few characteristics that require specific handling: they’re slow (seconds, not milliseconds), they have complex nested response structures, they support streaming, and the model selection and token management have real cost implications. This lesson is about building Go clients that handle all of this properly.</p> </article> <article> <h1>Lesson 3: Middleware with Tower Layers — The composable middleware pattern</h1> <p>Sat, 05 Oct 2024 08:30:00 +0000</p> <p>I once inherited a Node.js codebase with 23 Express middleware functions chained together. Half of them silently swallowed errors, three of them conflicted with each other, and nobody knew what order they ran in. When I started building services in Axum, the Tower middleware model felt like a revelation — not because it’s easier (it’s actually harder at first), but because it makes middleware <em>composable</em> and <em>type-checked</em>. You can’t silently swallow errors when the type system forces you to handle them.</p> </article> <article> <h1>Lesson 4: Escape Analysis Deep Dive — The compiler decides where your data lives</h1> <p>Sat, 05 Oct 2024 00:00:00 +0000</p> <p>I used to assume that every time I wrote <code>&someStruct{}</code> or returned a pointer from a function, I was creating a heap allocation. I was wrong — and the wrongness mattered for how I was designing APIs. After learning about escape analysis, I stopped guessing and started <em>asking the compiler</em> directly. This changed how I write Go.</p> <h2 id="the-problem">The Problem</h2> <p>Go has two places to put data: the <strong>stack</strong> and the <strong>heap</strong>. Stack allocations are cheap — they’re just a pointer bump, and the stack frame is reclaimed automatically when the function returns. Heap allocations go through the memory allocator, require garbage collection, and have non-trivial overhead.</p> </article> <article> <h1>Lesson 9: std::sync — Mutex, RwLock, Once, Barrier</h1> <p>Fri, 04 Oct 2024 13:25:00 +0000</p> <p>I shipped a data race to production exactly once. Go program, shared map, no lock. Took three weeks to reproduce — only happened under heavy load when two goroutines hit the same key simultaneously. The crash dump was useless. In Rust, that code wouldn’t have compiled. That’s not marketing — it’s literally how the type system works.</p> <h2 id="arc--shared-ownership-across-threads">Arc — Shared Ownership Across Threads</h2> <p>Before we talk about locks, we need <code>Arc</code>. You can’t share data between threads with just <code>Rc</code> — it’s not thread-safe. <code>Arc</code> (Atomic Reference Counted) is the thread-safe version.</p> </article> <article> <h1>Lesson 3: Paxos and Beyond — When Raft isn't enough</h1> <p>Fri, 04 Oct 2024 00:00:00 +0000</p> <p>After spending time with Raft, I found myself curious about the algorithm it was designed to replace. Paxos has a reputation: brilliant, correct, nearly impossible to implement correctly, and even harder to extend to practical systems. Leslie Lamport published the original Paxos paper in 1989, got it rejected, submitted a revised version in 1998, and it became the theoretical foundation for a generation of distributed systems. Chubby (Google’s distributed lock service), Zookeeper (the coordination service), and the precursor to Spanner all descended from Paxos thinking. Understanding why Raft was necessary requires understanding what Paxos gets right and where it falls short in practice.</p> </article> <article> <h1>Lesson 2: Axum from Zero — Routing, handlers, extractors</h1> <p>Thu, 03 Oct 2024 14:45:00 +0000</p> <p>The first time I tried Axum, I wrote a handler that took five extractor arguments and spent twenty minutes staring at a compiler error that said my function “didn’t implement Handler.” Turns out the order of extractors matters, and there’s a limit on how many you can have. Nobody tells you that upfront. So I’m telling you now.</p> <h2 id="routing-fundamentals">Routing Fundamentals</h2> <p>Axum’s router is just a struct that maps HTTP methods and paths to handler functions. No macros, no attributes — you build routes with method calls.</p> </article> <article> <h1>Lesson 12: Compression Basics — Why gzip works and entropy matters</h1> <p>Thu, 03 Oct 2024 00:00:00 +0000</p> <p>Every senior engineer I know makes compression decisions regularly: should this API response be gzip-compressed? Should logs be stored compressed? What compression level? Which algorithm? I made these decisions for years based on “gzip is standard, use it” without understanding why it worked or when something else might be better.</p> <p>Understanding the fundamentals of how compression works — entropy, Huffman coding, and LZ77 — changed how I think about data formats, wire protocols, and storage costs. It also helped me understand why some data compresses well and some data does not, which is critical for capacity planning.</p> </article> <article> <h1>Lesson 3: AST and Evaluation — Walking the tree to compute results</h1> <p>Thu, 03 Oct 2024 00:00:00 +0000</p> <p>After the lexer and parser, we have a tree. A beautiful, hierarchical, unambiguous representation of the program. Now we need to make it <em>do something</em>. The simplest way to execute a program from its AST is to walk the tree recursively and compute results as you go. No intermediate representation, no bytecode, no machine code — just a recursive function that pattern-matches on node types and returns values.</p> <p>This is a tree-walking interpreter. It is not the fastest approach (we cover bytecode and code generation in Lesson 4), but it is the most direct. Many production language implementations started here — and some, like early Ruby and Python, stayed here for a long time.</p> </article> <article> <h1>Lesson 6: Real-World Examples — Generics that survived code review</h1> <p>Wed, 02 Oct 2024 00:00:00 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 1: The Rust Web Landscape — Axum, Actix, Rocket and why I pick Axum</h1> <p>Tue, 01 Oct 2024 10:22:00 +0000</p> <p>I spent three weeks building a service in Actix-web before ripping it out and switching to Axum. Not because Actix was bad — it’s genuinely fast and battle-tested. I switched because every time I needed custom middleware, I was fighting the framework instead of writing my application. That experience taught me something: in Rust web development, the framework you pick determines how much you fight the type system versus how much you work <em>with</em> it.</p> </article> <article> <h1>Lesson 8: std::time — Duration, Instant, SystemTime</h1> <p>Tue, 01 Oct 2024 07:50:00 +0000</p> <p>A few months ago I tracked down a bug where a cache TTL check was wrong because someone compared <code>SystemTime</code> values that had been serialized and deserialized across a system clock adjustment. The cached timestamps jumped backward, and suddenly entries that should’ve expired were “fresh” again. That’s the kind of lesson that teaches you the difference between monotonic clocks and wall clocks.</p> <h2 id="two-clocks-two-types">Two Clocks, Two Types</h2> <p>Rust gives you two time types because computers have two fundamentally different clocks:</p> </article> <article> <h1>Lesson 4: Returning Concrete Types — Give callers the real thing</h1> <p>Tue, 01 Oct 2024 00:00:00 +0000</p> <p>There is a piece of Go advice that sounds almost too obvious to state, and yet I see it violated in production codebases every week: return concrete types from your functions. Not interfaces. Not <code>interface{}</code>. The actual, named, exported struct that your function produces.</p> <p>The reason this feels controversial is that it conflicts with object-oriented instincts. In Java and C#, returning an interface from a factory is considered good practice — it hides the implementation detail and “programs to an interface.” In Go, that instinct leads to information loss, surprise type assertions, and constructors that promise less than they deliver.</p> </article> <article> <h1>Lesson 3: encoding/json Beyond Basics — Custom marshalers, streaming, and the traps</h1> <p>Mon, 30 Sep 2024 00:00:00 +0000</p> <p><code>encoding/json</code> is one of the first packages every Go developer uses and one of the last they fully understand. The basic <code>json.Marshal</code> / <code>json.Unmarshal</code> API is approachable. But the package contains a whole layer of capabilities — custom marshaling, streaming decoders, <code>json.RawMessage</code> for deferred parsing, interface-type fields, and a surprising number of edge cases — that separate the code that works in demos from the code that works in production with adversarial inputs.</p> </article> <article> <h1>Lesson 7: std::process — Running external commands</h1> <p>Sun, 29 Sep 2024 19:15:00 +0000</p> <p>I once wrote a deployment script in Bash that grew to 800 lines with nested conditionals, string interpolation bugs, and error handling that amounted to “hope for the best.” Rewrote it in Rust using <code>std::process::Command</code> — same functionality, but with actual error handling and type safety. The number of failed deployments dropped to zero.</p> <h2 id="command--the-builder">Command — The Builder</h2> <p><code>std::process::Command</code> is a builder for spawning child processes. You construct the command, configure it, then either run it to completion or spawn it and interact with its I/O.</p> </article> <article> <h1>Lesson 4: Interface Placement — Define interfaces where they're used, not where they're implemented</h1> <p>Sat, 28 Sep 2024 00:00:00 +0000</p> <p>This is the Go idiom that surprises people coming from Java or C# the most. In those languages, you define an interface in the same place as (or even before) the implementation, and consumers import the interface. Go’s approach is the exact opposite, and it takes a while to internalize why. Once it clicks, it changes how you think about dependencies fundamentally.</p> <p>The rule is: define an interface in the package that needs it, not in the package that satisfies it. It sounds backwards. It is not. It is one of the most powerful design decisions the language enables.</p> </article> <article> <h1>Lesson 6: std::net — TCP, UDP, sockets</h1> <p>Fri, 27 Sep 2024 09:40:00 +0000</p> <p>The first network program I ever wrote — a chat server in college — had a bug where it would block forever waiting for one client’s message while all the other clients hung. Classic single-threaded socket mistake. Rust’s <code>std::net</code> module gives you the same low-level socket primitives, but the ownership system actually helps you avoid some of those pitfalls.</p> <h2 id="tcp--the-reliable-one">TCP — The Reliable One</h2> <p>TCP gives you ordered, reliable byte streams. You connect, you send bytes, they arrive in order (or the connection dies trying). That’s the deal.</p> </article> <article> <h1>Lesson 4: String and Byte Conversions — The copy nobody sees</h1> <p>Wed, 25 Sep 2024 00:00:00 +0000</p> <p>Go strings are immutable. Byte slices are mutable. Converting between them requires copying the data — every time, without exception, unless you use unsafe tricks you almost certainly shouldn’t. That sounds like a minor footnote, but it becomes a significant issue the moment you start handling large volumes of text: parsing HTTP requests, processing log lines, building JSON responses. I’ve watched a single <code>string(b)</code> call inside a tight loop add measurable latency to a production API, and the fix was two lines of code once I knew what to look for.</p> </article> <article> <h1>Lesson 5: std::fmt — Formatting internals</h1> <p>Tue, 24 Sep 2024 11:05:00 +0000</p> <p>I once shipped a monitoring dashboard where all the latency values showed up as “Duration { secs: 0, nanos: 234000000 }” because I’d used <code>{:?}</code> instead of implementing <code>Display</code>. That’s the kind of thing that makes you sit down and actually learn how formatting works.</p> <h2 id="display-vs-debug">Display vs. Debug</h2> <p>These two traits are the foundation of everything in <code>std::fmt</code>. Every time you use <code>println!</code>, <code>format!</code>, or <code>write!</code>, you’re invoking one of them.</p> </article> <article> <h1>Lesson 10: Testing CLI Applications — End-to-end CLI tests</h1> <p>Sun, 22 Sep 2024 12:10:00 +0000</p> <p>I shipped a CLI tool with 100% unit test coverage on the core logic. Users immediately found three bugs. The argument parser accepted <code>--port</code> but the value wasn’t being passed to the server. The <code>--json</code> flag produced output that wasn’t valid JSON because of a stray debug print. And <code>--help</code> showed the wrong default for <code>--timeout</code>. None of these bugs lived in the “core logic.” They lived in the glue between clap, the output formatter, and the actual binary. Unit tests didn’t catch them because unit tests don’t run the actual binary.</p> </article> <article> <h1>Lesson 3: Health Checks — Readiness vs liveness, and why both matter</h1> <p>Sun, 22 Sep 2024 00:00:00 +0000</p> <p>I’ve seen two types of health check implementations in production: the ones that always return 200 OK, and the ones that actually check something. The first kind is theater — Kubernetes thinks the pod is healthy and routes traffic to it, but the pod is actually deadlocked or its database connection pool is exhausted. The second kind is what saves you at 3am.</p> <p>Health checks are Kubernetes’s mechanism for deciding when a pod is ready to receive traffic and when it needs to be restarted. Get them right and Kubernetes becomes a genuinely reliable self-healing system. Get them wrong and you have an elaborate system that sends traffic to broken pods and restarts healthy ones.</p> </article> <article> <h1>Lesson 4: std::fs and std::path — Filesystem operations done right</h1> <p>Sat, 21 Sep 2024 16:10:00 +0000</p> <p>A colleague once deployed a script that used string concatenation for file paths: <code>dir + "/" + filename</code>. Worked perfectly on Linux, blew up on Windows, and silently corrupted paths when <code>dir</code> ended with a slash. Rust’s <code>Path</code> type exists specifically to prevent this class of bug.</p> <h2 id="path-vs-pathbuf--the-strstring-split">Path vs. PathBuf — The &str/String Split</h2> <p>Just like Rust has <code>&str</code> (borrowed) and <code>String</code> (owned), it has <code>&Path</code> (borrowed) and <code>PathBuf</code> (owned). The duality is identical:</p> </article> <article> <h1>Lesson 11: Design a Notification System — Push vs Pull, Priority, Dedup</h1> <p>Sat, 21 Sep 2024 00:00:00 +0000</p> <p>Notifications are the feature that can make or break user retention — and also destroy it. Done right, they bring users back at exactly the right moment. Done wrong, they’re spam that drives uninstalls. The system design challenge isn’t just the technical plumbing (though that’s interesting). It’s building infrastructure that’s fast for critical alerts, reliable for important messages, and smart enough to not overwhelm users with low-priority noise.</p> <h2 id="the-core-concept">The Core Concept</h2> <p>A notification system has to handle multiple channels with wildly different characteristics:</p> </article> <article> <h1>Lesson 4: Error Responses — Your API errors are your documentation</h1> <p>Fri, 20 Sep 2024 00:00:00 +0000</p> <p>I once integrated with an API that returned HTTP 200 for everything — successes and failures alike. The actual outcome was buried in a <code>status</code> field inside the JSON body. To know whether a request worked, you had to parse the response, check <code>status</code>, then switch on a string value that was inconsistently named across endpoints. Integrating with that API felt like defusing a bomb in the dark.</p> <p>How you design error responses is not a detail. It is part of your public interface.</p> </article> <article> <h1>Lesson 3: std::io — Read, Write, BufRead, Seek</h1> <p>Thu, 19 Sep 2024 08:30:00 +0000</p> <p>Early in my Rust journey, I wrote a log parser that read a 2GB file byte by byte using <code>read()</code> without buffering. It took forty minutes. Adding a <code>BufReader</code> wrapper — one line of code — brought it down to three seconds. That’s when I learned that understanding <code>std::io</code> isn’t optional.</p> <h2 id="the-four-core-traits">The Four Core Traits</h2> <p>Rust’s I/O system is built on four traits. Everything — files, network sockets, stdin, pipes, in-memory buffers — implements some combination of these:</p> </article> <article> <h1>Lesson 9: Building TUIs with ratatui — Terminal user interfaces</h1> <p>Thu, 19 Sep 2024 07:55:00 +0000</p> <p>I was monitoring a deployment through five separate terminal windows — one for logs, one for metrics, one for the deployment status, one for the database, and one running htop. Alt-tabbing between them like a madman. Then a colleague showed me their custom TUI dashboard that combined all five views into a single terminal screen, with tabs and live-updating graphs. It was written in Rust with ratatui. I rebuilt it that weekend.</p> </article> <article> <h1>Lesson 4: SSRF and Injection — The URL your user gave you might be localhost</h1> <p>Wed, 18 Sep 2024 00:00:00 +0000</p> <p>I reviewed a Go service that let users provide a “webhook URL” — we would call that URL when their account had a notification. The service fetched a preview of the URL to display in the UI. The developer who built it figured that since it only fetched the URL and never executed what was returned, it was safe. They had not considered that <code>http://169.254.169.254/latest/meta-data/iam/security-credentials/</code> is also a URL.</p> <p>SSRF — Server-Side Request Forgery — is the class of vulnerability where an attacker tricks your server into making an HTTP request to a target of their choosing, typically to access internal services that are not exposed to the internet. AWS instance metadata, Redis, internal Kubernetes API servers, admin dashboards, other services in your VPC — all are reachable from a server that blindly follows user-supplied URLs.</p> </article> <article> <h1>Lesson 2: Iterator Trait and Adapters — The full picture</h1> <p>Tue, 17 Sep 2024 14:45:00 +0000</p> <p>The moment Rust iterators clicked for me was when I realized they’re not loops with extra steps — they’re a completely different way of expressing data transformations. I’d been writing imperative loops for fifteen years, and the first time I refactored a gnarly nested-loop function into an iterator chain, the result was half the lines and twice as readable.</p> <h2 id="the-iterator-trait">The Iterator Trait</h2> <p>Everything starts here. The <code>Iterator</code> trait is shockingly simple:</p> </article> <article> <h1>Lesson 11: String Algorithms — KMP, Rabin-Karp, and why regex can be slow</h1> <p>Tue, 17 Sep 2024 00:00:00 +0000</p> <p>String processing sits at the foundation of almost every production system. Log parsing, protocol parsing, search, validation, templating — it all comes down to finding and transforming patterns in text. Most of the time, strings.Contains or a simple loop is fast enough. But when you are processing millions of log lines per second, or running user-supplied patterns against untrusted input, or implementing a search feature that needs to handle long documents, naive string matching becomes a bottleneck or a security hole.</p> </article> <article> <h1>Lesson 8: Distribution — Static binaries, cargo-dist, Homebrew</h1> <p>Mon, 16 Sep 2024 19:40:00 +0000</p> <p>I built a CLI tool that three teams at work used daily. It lived in a shared directory on an NFS mount. Every time I pushed an update, I’d post in Slack: “new version in /shared/tools, please copy it to your PATH.” Half the team was running a version from three months ago because they forgot. The other half had four copies scattered across their home directories. Distribution matters. If installing your tool is harder than <code>brew install myapp</code>, most people won’t bother.</p> </article> <article> <h1>Lesson 12: Ring Buffers — Fixed-size queues for real-time systems</h1> <p>Mon, 16 Sep 2024 00:00:00 +0000</p> <p>The ring buffer is the data structure that makes real-time systems possible. Audio processing, network packet capture, kernel I/O buffers, metrics collection — anywhere you have a producer and a consumer that need to exchange data with zero allocation and bounded latency, you’ll find a ring buffer.</p> <p>It’s also one of the most elegant structures in systems programming: a fixed-size array, two indices, and one invariant. Let me show you how it works and why it appears everywhere from Linux kernel drivers to Disruptor (the LMAX exchange’s million-transactions-per-second queue).</p> </article> <article> <h1>Lesson 1: Collections Deep Dive — Vec, VecDeque, BTreeMap and when to use which</h1> <p>Sun, 15 Sep 2024 10:22:00 +0000</p> <p>I spent two days debugging a performance cliff in a data pipeline — turns out I’d been using a <code>HashMap</code> where a <code>BTreeMap</code> would’ve cut iteration time in half because I needed sorted output downstream. The collection you pick matters more than most people think.</p> <h2 id="the-big-picture">The Big Picture</h2> <p>Rust’s standard library ships a small but deliberate set of collections. Unlike languages that give you seventeen flavors of list, Rust gives you a few well-designed options and expects you to understand the trade-offs. That’s actually a feature — fewer choices means you can develop genuine intuition about when to use what.</p> </article> <article> <h1>Lesson 3: Distributed Tracing with OpenTelemetry — Follow the request across services</h1> <p>Sun, 15 Sep 2024 00:00:00 +0000</p> <p>We had an incident where checkout was timing out intermittently. The logs showed the API gateway receiving the request and returning a 504 after 30 seconds. The payment service logged nothing. The inventory service logged nothing. Something was hanging somewhere in the middle, and we had no way to see where.</p> <p>I spent four hours bisecting the call graph by adding temporary log lines, redeploying, and re-triggering the error. We eventually found a database query in the inventory service that was waiting on a lock — a lock held by a background job nobody had thought to instrument. Logs told me what each service did in isolation. They told me nothing about the shape of a single request as it flowed across all of them.</p> </article> <article> <h1>Lesson 7: Cross-Compilation for Linux, Mac, Windows — Build once, run anywhere</h1> <p>Sat, 14 Sep 2024 10:25:00 +0000</p> <p>First time I tried to cross-compile a Rust binary from my Mac to Linux, I ran <code>cargo build --target x86_64-unknown-linux-gnu</code> and got hit with a wall of linker errors. Missing <code>cc</code>, wrong <code>libc</code>, something about <code>crt1.o</code>. It felt like the “build once, run anywhere” promise was a lie. It wasn’t — I just didn’t understand how Rust’s compilation model interacts with system libraries. Once that clicked, cross-compilation became routine.</p> <h2 id="how-rust-compilation-works">How Rust Compilation Works</h2> <p>Rust compiles to LLVM IR, then LLVM generates machine code for the target architecture. That part works across platforms — LLVM knows how to emit x86_64, aarch64, arm, riscv, wasm, and more. The problem is the <em>linker</em>.</p> </article> <article> <h1>Lesson 4: Design WhatsApp — End-to-end encryption, message delivery guarantees, presence</h1> <p>Sat, 14 Sep 2024 00:00:00 +0000</p> <p>WhatsApp is deceptively simple from a user perspective: you send a message, it arrives. But building a messaging system that handles 100 billion messages per day with end-to-end encryption, reliable delivery semantics, and real-time presence for 2 billion users is a genuinely hard engineering problem. I find this problem particularly instructive because it forces you to confront three things simultaneously: cryptographic key management, message delivery guarantees, and the cost of maintaining online/offline state at massive scale.</p> </article> <article> <h1>Lesson 2: Projections and Read Models — Build any view from your event stream</h1> <p>Fri, 13 Sep 2024 00:00:00 +0000</p> <p>After I shipped the event-sourced account system, the first question from the product team was: “Can we have a page that shows all accounts that have been dormant for more than 90 days?” In a traditional system, this is a query: <code>SELECT * FROM accounts WHERE last_activity < NOW() - INTERVAL '90 days'</code>. In event sourcing, there’s no <code>last_activity</code> column — there’s an event stream. My first instinct was to query the event store directly, find the latest event per stream, and filter. It worked. Then they asked for the top 100 accounts by balance. Then active accounts by geography. Then a real-time dashboard with all of the above simultaneously. Querying the event store for each of these is either very slow or very complex. The answer is projections — pre-computed read models built from your event streams.</p> </article> <article> <h1>Lesson 3: File I/O Patterns — Read, write, stream without loading everything into memory</h1> <p>Thu, 12 Sep 2024 00:00:00 +0000</p> <p>CLI tools spend most of their life doing file I/O. Reading config files, processing log dumps, writing output, transforming data from stdin to stdout — it all comes down to bytes moving through your program. The difference between a CLI tool that handles 100MB files gracefully and one that runs out of memory on large inputs is almost always whether you read everything into memory or stream it.</p> <p>Go’s standard library gives you everything you need to stream data efficiently. The key is knowing which functions to reach for and which ones to avoid when the input is large or unknown in size.</p> </article> <article> <h1>Lesson 6: Subcommands and Complex CLI Structures — git-style interfaces</h1> <p>Wed, 11 Sep 2024 13:50:00 +0000</p> <p>Every tool starts as <code>mytool --flag input.txt</code>. Then someone asks for a second mode. Then a third. Before you know it, you have <code>mytool --mode=convert --input foo --output bar</code> and <code>mytool --mode=validate --strict --input foo</code> and users are scrolling through <code>--help</code> trying to find the three flags that matter for their use case. The answer is subcommands. <code>git commit</code>, <code>docker build</code>, <code>cargo test</code> — separate commands with separate flags, unified under one binary.</p> </article> <article> <h1>Lesson 2: Inter-Service Communication — HTTP, gRPC, or events? It depends on the coupling.</h1> <p>Tue, 10 Sep 2024 00:00:00 +0000</p> <p>Every time I’ve seen a team choose their inter-service communication protocol by default — “we’ll use REST for everything” or “we’re going gRPC-native” — they’ve ended up with a transport mechanism that fights against some of their use cases. The choice between HTTP, gRPC, and event-driven messaging is a question about coupling: how tightly do these services need to be synchronized? The answer to that question selects your transport, not the other way around.</p> </article> <article> <h1>Lesson 5: Signal Handling and Graceful Shutdown — Clean exits</h1> <p>Mon, 09 Sep 2024 09:17:00 +0000</p> <p>I had a CLI tool that converted video files. Big ones — 10, 20 gigabytes each. The conversion created a temp file, wrote the converted output there, then renamed it to the final destination. Hit Ctrl+C at the wrong moment and you’d get a half-written 15GB temp file sitting on disk. Users ran out of disk space without knowing why. All because I never handled signals properly.</p> <h2 id="what-happens-when-you-press-ctrlc">What Happens When You Press Ctrl+C</h2> <p>When you press Ctrl+C in a terminal, the kernel sends <code>SIGINT</code> (signal interrupt) to the foreground process group. By default, this kills your program immediately. No destructors run. No <code>Drop</code> implementations execute. Temporary files stay on disk. Database connections aren’t closed. Partial writes aren’t rolled back.</p> </article> <article> <h1>Lesson 10: Vacuum and Bloat — Why Postgres Tables Grow</h1> <p>Mon, 09 Sep 2024 00:00:00 +0000</p> <p>I watched a Postgres instance run out of disk space on a 500 GB SSD. The database had 50 GB of actual data. The other 450 GB was table bloat — dead row versions from MVCC that vacuum had failed to clean up. A batch job had been running long-running transactions for weeks, holding a transaction horizon that prevented vacuum from reclaiming anything. By the time we noticed, the disk was nearly full and autovacuum was struggling to catch up. Understanding why this happens — and how to prevent it — is one of the most important operational skills for running Postgres in production.</p> </article> <article> <h1>Lesson 12: Test Architecture — When to unit, integration, or e2e</h1> <p>Sun, 08 Sep 2024 11:10:00 +0000</p> <p>I inherited a Rust project with 800 tests. Running them took 45 minutes. I dug in and found: 600 unit tests that mocked every dependency (most tested nothing meaningful), 180 integration tests that duplicated what the unit tests already covered, and 20 end-to-end tests that were flaky because they hit a staging server. The project had <em>more tests</em> than any codebase I’d seen — and also <em>more bugs</em>. The volume was high, but the strategy was garbage.</p> </article> <article> <h1>Lesson 2: Schema Design — Types, queries, mutations, and subscriptions</h1> <p>Sun, 08 Sep 2024 00:00:00 +0000</p> <p>The schema is the most important artifact in any GraphQL API. It is simultaneously the contract between your client and server, the documentation for every engineer who works with the API, and the boundary that forces you to think clearly about your domain before writing any implementation code. A well-designed schema makes everything easier. A poorly designed schema compounds every mistake downstream.</p> <p>I’ve seen both. The experience of inheriting a badly designed GraphQL schema — full of inconsistent naming, misused types, nullable fields everywhere because someone wasn’t sure — is one of the more persistent forms of technical debt I’ve encountered. Unlike a poorly written function, a bad schema is public-facing. You can’t just refactor it; you have to version and deprecate carefully.</p> </article> <article> <h1>Lesson 5: Anti-Patterns — Just because you can doesn't mean you should</h1> <p>Sun, 08 Sep 2024 00:00:00 +0000</p> <p>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.</p> <p>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 <em>can</em> look like.</p> </article> <article> <h1>Lesson 4: Colored Output and Progress Bars — UX for the terminal</h1> <p>Sat, 07 Sep 2024 16:33:00 +0000</p> <p>I used to think terminal output was either plain text or ANSI escape code soup. Then I looked at how tools like <code>cargo</code>, <code>ripgrep</code>, and <code>bat</code> handle their output — color used purposefully to draw the eye, progress bars that give you actual information, spinners that tell you something is happening. Good terminal UX isn’t about making things pretty. It’s about making information scannable.</p> <h2 id="raw-ansi-escape-codes">Raw ANSI Escape Codes</h2> <p>Before using any crate, you should understand what’s actually happening. Terminal colors are just special byte sequences embedded in the output stream:</p> </article> <article> <h1>Lesson 7: Recursion — Trust the Recursion, Define the Base Case</h1> <p>Sat, 07 Sep 2024 00:00:00 +0000</p> <p>Recursion trips people up not because the concept is hard, but because they try to trace through it. “If I call <code>f(3)</code>, then <code>f(3)</code> calls <code>f(2)</code>, which calls <code>f(1)</code>…” and then they lose the thread. I used to do this. My interviewer at a Series B startup once watched me spend three minutes trying to mentally simulate a recursive call stack for a problem that had a two-line solution once I stopped simulating and started trusting.</p> </article> <article> <h1>Lesson 10: Design a News Feed — Fan-out on Write vs Read</h1> <p>Fri, 06 Sep 2024 00:00:00 +0000</p> <p>The news feed is the product feature that defines social media. Every time you open Instagram or Twitter, you see a personalized, ranked, real-time stream of content from people you follow. Behind that deceptively simple UI is one of the hardest distributed systems problems in consumer tech: how do you compute a personalized feed for hundreds of millions of users, where any piece of content needs to appear in potentially millions of feeds, within seconds of being posted?</p> </article> <article> <h1>Lesson 11: Testing in CI — GitHub Actions for Rust</h1> <p>Thu, 05 Sep 2024 16:45:00 +0000</p> <p>I merged a PR last year that passed all tests on my M2 MacBook and broke on the Linux CI runner. The issue? I’d used <code>std::path::PathBuf</code> with hardcoded forward slashes, which worked fine on macOS but blew up on Linux because the test setup expected a specific path format. CI exists to catch exactly this kind of “it works on my machine” problem. Here’s how to set it up properly for Rust.</p> </article> <article> <h1>Lesson 3: Configuration Files and Environment Variables — Config that scales</h1> <p>Thu, 05 Sep 2024 11:08:00 +0000</p> <p>I shipped a CLI tool with 23 flags once. Twenty-three. The <code>--help</code> output scrolled past two terminal screens. Users hated it, nobody could remember the flags, and every deployment script was a wall of backslash-continued command lines. That’s when I learned: if your tool has more than about eight flags, you need a configuration file.</p> <h2 id="the-configuration-hierarchy">The Configuration Hierarchy</h2> <p>Every serious CLI tool follows the same precedence order:</p> <ol> <li>Command-line flags (highest priority)</li> <li>Environment variables</li> <li>Project-local config file (<code>.myapp.toml</code> in the current directory)</li> <li>User config file (<code>~/.config/myapp/config.toml</code>)</li> <li>System config file (<code>/etc/myapp/config.toml</code>)</li> <li>Compiled-in defaults (lowest priority)</li> </ol> <p>Each layer overrides the one below it. This lets users set defaults in their home directory, override them per-project, and override those on a per-invocation basis with flags. kubectl, git, docker — they all work this way.</p> </article> <article> <h1>Lesson 3: Global Mutable State — The variable that breaks every test</h1> <p>Thu, 05 Sep 2024 00:00:00 +0000</p> <p>There was a test suite I worked on where tests passed individually but failed when run together. The failure pattern was non-deterministic — sometimes test A broke test B, sometimes test C broke test A, and it changed with the <code>-count</code> flag. After two hours of bisecting, we found it: a package-level <code>var config Config</code> that every test modified by calling <code>loadConfig("testdata/some-fixture.json")</code>. The tests were sharing state without knowing it, and the one that ran last set the config for all the others.</p> </article> <article> <h1>Lesson 3: Idiomatic Naming — Names are your documentation</h1> <p>Wed, 04 Sep 2024 00:00:00 +0000</p> <p>When I review Go code, naming problems tell me more about the author’s understanding of the codebase than almost anything else. A function called <code>HandleRequest</code> that parses JSON, queries a database, formats a response, and writes to a log tells me its author didn’t know what it does either. A variable called <code>data</code> in a function that handles three different kinds of data tells me the author stopped thinking halfway through. Names are the first layer of documentation — they’re read far more often than comments, and unlike comments, they can’t drift out of sync with the code.</p> </article> <article> <h1>Lesson 2: stdin, stdout, stderr — I/O patterns</h1> <p>Tue, 03 Sep 2024 08:45:00 +0000</p> <p>A coworker once asked me to review a Rust CLI they’d written. It read a CSV file, transformed some columns, and wrote the result. Worked perfectly — until someone piped in a 2GB file. The tool ate 4GB of RAM, hung for thirty seconds, then crashed. They were reading the entire file into a <code>String</code> before processing a single line. Classic.</p> <h2 id="why-io-is-harder-than-it-looks">Why I/O Is Harder Than It Looks</h2> <p>Unix tools work because of a simple contract: read from stdin, write to stdout, errors to stderr. <code>cat file | grep pattern | sort | uniq -c</code>. Each program does one thing. They compose through pipes. It’s beautiful when it works.</p> </article> <article> <h1>Lesson 11: Skip Lists — How Redis sorted sets work</h1> <p>Tue, 03 Sep 2024 00:00:00 +0000</p> <p>Redis chose skip lists for its sorted set implementation, and that choice is more interesting than it first appears. When you have <code>ZADD</code>, <code>ZRANGE</code>, and <code>ZRANK</code> all needing to run at O(log n), you might reach for a balanced BST. But Redis chose a probabilistic alternative that’s simpler to implement, easier to reason about in concurrent contexts, and performs comparably in practice.</p> <p>Understanding skip lists taught me something important about engineering tradeoffs: sometimes “good enough with simpler code” beats “optimal but complex.”</p> </article> <article> <h1>Lesson 10: Benchmarking with criterion — Measure, don't guess</h1> <p>Mon, 02 Sep 2024 13:20:00 +0000</p> <p>I once optimized a hot loop by replacing a <code>HashMap</code> lookup with a <code>Vec</code> indexed by a precomputed key. Felt clever. Ran the benchmarks. The “optimized” version was 15% <em>slower</em> because the <code>Vec</code> was huge, cache-cold, and the access pattern was random. Without the benchmark, I would’ve shipped that “improvement” and bragged about it. Performance intuition is unreliable. Measurement isn’t.</p> <h2 id="the-problem">The Problem</h2> <p>Rust is fast by default, but that doesn’t mean your code is fast. You can still write O(n^2) algorithms, cause cache thrashing, allocate unnecessarily, or clone data you could borrow. Worse, optimizations that seem obvious can backfire in ways you don’t expect.</p> </article> <article> <h1>Lesson 10: Backtracking — Constraint satisfaction and config generation</h1> <p>Mon, 02 Sep 2024 00:00:00 +0000</p> <p>Backtracking is the algorithmic equivalent of “try everything, but be smart about giving up early.” It is a systematic way to explore a search space where you build a solution incrementally and abandon partial solutions as soon as you detect they cannot possibly lead to a valid result.</p> <p>I first encountered backtracking outside of textbooks when building a scheduling system that needed to assign employees to shifts while respecting availability constraints, skill requirements, and labor regulations. The brute force approach — enumerate all possible assignments — was computationally equivalent to exploring all permutations, which was 20! for 20 employees. Backtracking with constraint pruning reduced the search space by several orders of magnitude.</p> </article> <article> <h1>Lesson 1: clap — Argument parsing done right</h1> <p>Sun, 01 Sep 2024 14:22:00 +0000</p> <p>I’ve written argument parsers by hand in four different languages. Every single time, I ended up with a tangled mess of string matching, edge cases around flags that take optional values, and help text that drifted out of sync with reality within a week. Then I found clap.</p> <h2 id="the-problem-with-rolling-your-own">The Problem With Rolling Your Own</h2> <p>Parsing command-line arguments <em>seems</em> simple. You grab <code>std::env::args()</code>, maybe split on <code>=</code>, handle some <code>--flag</code> and <code>-f</code> cases. Works great until someone passes <code>--output=</code> with no value. Or uses <code>-vvv</code> for triple verbosity. Or expects <code>--help</code> to just work. Or wants <code>--color=always|never|auto</code>. Suddenly your 40-line parser is 400 lines of spaghetti.</p> </article> <article> <h1>Lesson 4: HTTP Handler Testing — httptest is your best friend</h1> <p>Sun, 01 Sep 2024 00:00:00 +0000</p> <p>Every Go HTTP handler is just a function that takes a <code>ResponseWriter</code> and a <code>*Request</code>. That’s the entire contract. The fact that the standard library ships with a testing package that lets you call that function with a fake writer and a real request — without starting a server, without binding a port — is a gift that too many people overlook. I spent months spinning up actual servers in tests before I discovered <code>net/http/httptest</code>. I will not let you make the same mistake.</p> </article> <article> <h1>Lesson 9: Code Coverage — tarpaulin and llvm-cov</h1> <p>Fri, 30 Aug 2024 07:55:00 +0000</p> <p>I worked on a team that had a strict “90% code coverage” policy. Every PR had to hit that number or it got rejected. The result? People wrote tests like <code>assert!(true)</code> just to touch lines. We had 92% coverage and bugs everywhere. Coverage is a useful signal. It’s a terrible goal.</p> <p>That said, knowing <em>which</em> lines your tests don’t touch is genuinely valuable. It tells you where your blind spots are. Here’s how to measure it in Rust.</p> </article> <article> <h1>Lesson 3: Circuit Breaking — Stop calling the service that's already down</h1> <p>Wed, 28 Aug 2024 00:00:00 +0000</p> <p>There’s a particular kind of production incident that goes like this: Service A calls Service B. Service B starts responding slowly because its database is under pressure. Service A’s goroutines pile up waiting for responses. After a few minutes, Service A is out of memory, and now two services are down instead of one. The postmortem note says “cascading failure.” The fix, which nobody implemented, is a circuit breaker.</p> <p>The circuit breaker pattern comes from electrical engineering. When too much current flows through a circuit, the breaker trips — it opens the circuit and prevents more current from flowing until someone resets it. In software, the “current” is requests, and “tripping” means refusing to make calls to a failing downstream instead of piling up timeouts and consuming resources.</p> </article> <article> <h1>Lesson 8: Snapshot Testing with insta — Catch regressions instantly</h1> <p>Tue, 27 Aug 2024 10:30:00 +0000</p> <p>I refactored a code formatter once — changed how it handles indentation for nested blocks. I had assertions checking specific outputs for five test cases, and they all passed. But the formatter produced subtly different output for a sixth pattern I hadn’t tested, and a user filed a bug three days later. If I’d had snapshot tests, I would’ve seen every output change in a diff during the refactor. Five minutes of review instead of three days of embarrassment.</p> </article> <article> <h1>Lesson 1: Go Plugins and hashicorp/go-plugin — Extending Go apps without recompiling</h1> <p>Mon, 26 Aug 2024 00:00:00 +0000</p> <p>The first time I needed a plugin system in Go, I went straight to <code>plugin.Open</code> in the standard library. Ten minutes later I was reading about RTLD flags and shared library loading on Linux, discovering that plugins had to be compiled with the same Go toolchain version as the host, and learning that once a plugin was loaded it could not be unloaded. My enthusiasm dropped sharply. Then I found <code>hashicorp/go-plugin</code> and understood that the Go community had largely agreed: real plugin systems in Go should run plugins as separate processes communicating over RPC, not as shared libraries in the same process.</p> </article> <article> <h1>Lesson 3: Method Sets and Addressability — Why your value can't satisfy that interface</h1> <p>Sun, 25 Aug 2024 00:00:00 +0000</p> <p>I spent a solid twenty minutes staring at a compilation error that read “does not implement interface (Write method has pointer receiver)” and thinking: I <em>can see</em> the Write method right there. What is Go complaining about? Once I understood method sets and why addressability matters, the rule became obvious — and I have never needed to look it up since.</p> <h2 id="the-problem">The Problem</h2> <p>Go lets you define methods with either a value receiver or a pointer receiver:</p> </article> <article> <h1>Lesson 7: Fuzz Testing with cargo-fuzz — Breaking your code automatically</h1> <p>Sat, 24 Aug 2024 20:05:00 +0000</p> <p>A friend of mine maintains a binary parser in Rust. It had hundreds of unit tests, property tests, the works. He ran a fuzzer against it on a Friday afternoon, left it running over the weekend. Monday morning: 23 unique crashes. Some were panics from unexpected inputs. Two were infinite loops. One was a stack overflow from deeply nested structures. All from inputs no human would ever think to construct.</p> </article> <article> <h1>Lesson 9: Partitioning — Range, Hash, List and When Each Helps</h1> <p>Sat, 24 Aug 2024 00:00:00 +0000</p> <p>I have worked with a few systems that had grown their main tables to 500 million rows or more. At that scale, even well-indexed queries start slowing down — not because the indexes are wrong, but because the index itself becomes large and the buffer cache can only hold so many pages. Vacuum struggles to keep up. <code>EXPLAIN</code> output looks fine but queries still feel sluggish. Partitioning is the architectural solution to this class of problem: instead of one big table, you have many smaller tables that look like one from the application’s perspective.</p> </article> <article> <h1>Lesson 8: Technical Debt — When to pay, when to live with it</h1> <p>Fri, 23 Aug 2024 00:00:00 +0000</p> <p>The term “technical debt” gets used to mean everything from “this code is a mess” to “we made a pragmatic shortcut we need to revisit” to “this system has grown organically and nobody understands it anymore.” These are different problems requiring different responses. Treating all technical debt as something that must be paid now, or all of it as something acceptable to defer indefinitely — both lead to bad outcomes. The skill is knowing which debt to address, when, and how.</p> </article> <article> <h1>Lesson 6: Property-Based Testing with proptest — Let the computer find your bugs</h1> <p>Thu, 22 Aug 2024 15:40:00 +0000</p> <p>I wrote a URL parser once. Had fifty hand-crafted test cases. All green. Pushed to production. Within a week, a user sent a URL with a percent-encoded space followed by a Unicode character, and the parser crashed. I never would have thought to write that test case. A property-based test would have found it in under a second.</p> <h2 id="the-problem">The Problem</h2> <p>When you write tests by hand, you test the cases you think of. But bugs don’t live in the cases you think of — they live in the ones you don’t. Your test for <code>sort([3, 1, 2])</code> passes, but does your sort handle a list with ten million duplicates? A list of all negative numbers? An empty list? A list with <code>i32::MAX</code> and <code>i32::MIN</code> adjacent?</p> </article> <article> <h1>Lesson 3: Interface Pollution — More interfaces means more indirection</h1> <p>Thu, 22 Aug 2024 00:00:00 +0000</p> <p>Interface pollution is not a hypothetical risk. I have walked into codebases where more than half the types in the package are interfaces, where every function parameter is an interface even when the concrete type is never substituted, and where adding a new feature means navigating six files just to trace what a single method call actually does. The code is technically “flexible” in the sense that every seam is abstract. In practice it is a maze with no map.</p> </article> <article> <h1>Lesson 9: Design a Chat System — WebSocket, Presence, Message Ordering</h1> <p>Wed, 21 Aug 2024 00:00:00 +0000</p> <p>Building a chat system is the interview problem that catches people on protocol fundamentals. HTTP is a request-response protocol — the client asks, the server answers, and then the connection is idle. For chat, the server needs to push messages to clients the moment they arrive. This inversion of the HTTP model is what makes chat hard, and it’s what drives the entire architecture.</p> <h2 id="the-core-concept">The Core Concept</h2> <p><strong>Why HTTP polling doesn’t work at scale</strong></p> </article> <article> <h1>Lesson 3: Slice and Map Performance — The data structure tax</h1> <p>Tue, 20 Aug 2024 00:00:00 +0000</p> <p>Slices and maps are so convenient in Go that it’s easy to forget they’re not free. They have hidden costs — in allocations, in CPU cache misses, in GC scanning time — that only become visible when you push them into a hot path and watch your benchmarks light up. I’ve been burned by both, sometimes in embarrassing ways, and building intuition for when those costs matter has saved me more than one production incident.</p> </article> <article> <h1>Lesson 5: Mocking — mockall and faking dependencies</h1> <p>Mon, 19 Aug 2024 08:15:00 +0000</p> <p>I spent an embarrassing amount of time early in my Rust journey trying to mock a database connection by hand. I built a fake struct, implemented the trait, tracked method calls with <code>RefCell<Vec<...>></code> wrappers, wrote expectation-checking logic… and ended up with 200 lines of mock code to test 15 lines of business logic. Then I found <code>mockall</code> and felt like an idiot.</p> <h2 id="the-problem">The Problem</h2> <p>Real code has dependencies. Your payment processor calls Stripe. Your user service queries a database. Your notification system sends emails. You can’t — and shouldn’t — hit these real services in unit tests. They’re slow, flaky, expensive, and non-deterministic.</p> </article> <article> <h1>Lesson 10: Bloom Filters — Probably yes, definitely no</h1> <p>Mon, 19 Aug 2024 00:00:00 +0000</p> <p>There’s a beautiful data structure that will tell you one of two things: “definitely not in the set” or “probably in the set.” That asymmetry — where false negatives are impossible but false positives are allowed — turns out to be useful in an enormous number of production scenarios.</p> <p>Bloom filters use a fraction of the memory of a hash set, and the math behind their false positive rate is surprisingly elegant. Once you understand them, you’ll see why databases, CDNs, and distributed caches reach for them constantly.</p> </article> <article> <h1>Lesson 3: internal/ Usage Patterns — Compiler-enforced encapsulation</h1> <p>Sun, 18 Aug 2024 00:00:00 +0000</p> <p>Go does not have access modifiers in the Java or Kotlin sense. There is no <code>protected</code>, no <code>package-private</code>, no friend classes. You get exactly two visibility levels: exported (capital letter) and unexported (lowercase letter). That simplicity is a feature. But it creates a gap: how do you share something across packages within your own module without accidentally exposing it to the outside world?</p> <p>The answer is <code>internal/</code>. It is one of the most underused and underappreciated tools in Go’s package system, and it is enforced by the compiler itself.</p> </article> <article> <h1>Lesson 4: Test Fixtures and Setup/Teardown — Reusable test infrastructure</h1> <p>Sat, 17 Aug 2024 11:30:00 +0000</p> <p>I had a test file last year where every single test started with the same twelve lines of setup — creating a database connection, inserting seed data, configuring a logger. Twelve lines, copy-pasted forty times. When I needed to change the seed data, I had to update forty tests. I missed three. Those three tests silently tested against stale data for two months.</p> <p>Fixtures exist to prevent this kind of insanity.</p> </article> <article> <h1>Lesson 9: Greedy Algorithms — When being selfish is optimal</h1> <p>Sat, 17 Aug 2024 00:00:00 +0000</p> <p>Greedy algorithms have a simple idea at their core: at each step, make the locally optimal choice. No looking ahead, no considering alternatives, no backtracking. Just take the best available option right now and trust that it leads to a globally optimal result.</p> <p>The catch is that this only works for specific problem structures. Use greedy when the problem has the <strong>greedy choice property</strong> — the locally optimal choice is always part of a globally optimal solution. When this holds, greedy is elegant and fast. When it does not, greedy gives you a wrong answer with no warning.</p> </article> <article> <h1>Lesson 2: io Patterns — Reader, Writer, and the composability that makes Go great</h1> <p>Fri, 16 Aug 2024 00:00:00 +0000</p> <p>The <code>io</code> package is three hundred lines of interface definitions and a handful of utility functions. It is also the spine of the entire Go standard library. Every package that reads or writes data — <code>os</code>, <code>net</code>, <code>compress/gzip</code>, <code>crypto/tls</code>, <code>encoding/json</code>, <code>bufio</code> — does it through <code>io.Reader</code> and <code>io.Writer</code>. Once you understand these two interfaces, the standard library clicks into place as one coherent system.</p> <p>I spent my first few months with Go treating <code>io.Reader</code> as the thing that HTTP response bodies happen to be. It wasn’t until I built a streaming CSV processor — piping data from S3 through gzip decompression into a CSV parser, all without loading the file into memory — that I understood what the interfaces were actually designed for.</p> </article> <article> <h1>Lesson 2: Performance Costs — reflect.ValueOf is not free</h1> <p>Thu, 15 Aug 2024 00:00:00 +0000</p> <p>Every time I see reflection in a hot path, I know there is a performance conversation waiting to happen. Reflection in Go is not arbitrarily slow — it is predictably and measurably slow in specific ways. Understanding those costs, benchmarking them in your context, and knowing the standard mitigation patterns (primarily caching) lets you use reflection where it belongs without making your application noticeably slower.</p> <p>The performance story of reflection has two parts: the cost of type inspection (getting a <code>reflect.Type</code>, reading fields, checking kinds) and the cost of value operations (getting a <code>reflect.Value</code>, reading or setting field values, calling methods). Type inspection is expensive the first time and cheap if cached. Value operations are expensive every time and there is no way to avoid that cost except to reduce how often you do them.</p> </article> <article> <h1>Lesson 3: Doc Tests — Tested documentation</h1> <p>Wed, 14 Aug 2024 18:10:00 +0000</p> <p>I once read the docs for a popular Rust crate, copied the example verbatim, and it didn’t compile. The API had changed two versions ago but nobody updated the docs. I spent twenty minutes debugging code that was supposed to be the “getting started” guide. Rust has a built-in solution to this exact problem, and it’s one of the most underappreciated features in the language.</p> <h2 id="the-problem">The Problem</h2> <p>Documentation lies. Not on purpose — it lies because code evolves and docs don’t. A function signature changes, a parameter gets renamed, a return type shifts from <code>String</code> to <code>&str</code>, and the example in the docstring quietly becomes fiction. No compiler warning, no test failure, just a frustrated user copy-pasting broken code.</p> </article> <article> <h1>Lesson 2: Leadership and Conflict — The questions that decide senior vs mid-level</h1> <p>Wed, 14 Aug 2024 00:00:00 +0000</p> <p>There’s a specific moment in every senior-level interview loop where the conversation shifts. The system design round wraps up, the coding is done, and then an interviewer leans back and asks something like: “Tell me about a time you had to push back on a product decision you thought was wrong.” Or: “Describe a situation where you disagreed with your tech lead and how you handled it.”</p> <p>These are not softballs. For companies hiring at senior or staff level, behavioral questions about leadership and conflict are often the deciding signal. Everyone who makes it to that round can code. Not everyone can navigate the organizational and interpersonal dynamics of a senior role. These questions are trying to separate the two.</p> </article> <article> <h1>Lesson 4: Interfaces vs Generics — Behavior or data shape? That's your answer</h1> <p>Wed, 14 Aug 2024 00:00:00 +0000</p> <p>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.</p> <p>Here’s the question I ask myself every time: <strong>Is what varies the behavior, or the data shape?</strong> That single question gets me to the right answer ninety percent of the time.</p> </article> <article> <h1>Lesson 8: Memory-Mapped IO — How Databases Read Files</h1> <p>Tue, 13 Aug 2024 00:00:00 +0000</p> <p>I was reading about how RocksDB works one evening and kept seeing references to <code>mmap</code> for reads. I had heard of memory-mapped files but thought of them as a niche optimization. Then I realized: SQLite uses mmap. WiredTiger (MongoDB’s storage engine) uses mmap. LMDB is built almost entirely around mmap. Even some Postgres configurations use mmap for WAL. Understanding mmap explains a lot about how high-performance storage works, why some databases are so fast for random reads, and why memory and I/O are so deeply intertwined at the OS level.</p> </article> <article> <h1>Lesson 2: Integration Tests — The tests/ directory</h1> <p>Mon, 12 Aug 2024 09:45:00 +0000</p> <p>A colleague once reviewed one of my Rust libraries and said, “Your unit tests pass, but I can’t actually use the crate — the public API doesn’t compose the way anyone would expect.” He was right. I’d tested every internal function meticulously and completely ignored the experience of someone actually calling my library from the outside. That’s the gap integration tests fill.</p> <h2 id="the-problem">The Problem</h2> <p>Unit tests live inside your source files and can access private functions. That’s great for verifying internal logic, but it creates a blind spot: you never validate that your <em>public API</em> actually makes sense. You can have perfect internal functions that combine into a terrible user experience.</p> </article> <article> <h1>Lesson 3: TLS Configuration — Your default HTTP server is unencrypted</h1> <p>Mon, 12 Aug 2024 00:00:00 +0000</p> <p>When I started writing Go HTTP servers, I thought TLS was someone else’s problem. A load balancer in front of my service handled HTTPS termination, so my service only ever spoke plain HTTP on the internal network. That is a common and often defensible architecture. But it means that if anyone gains access to your internal network — a compromised service, a misconfigured cloud security group, a rogue container — all traffic between your services is plaintext. I learned this lesson not from a breach but from a penetration test report that listed it as a finding with a crisp paragraph explaining exactly why it mattered.</p> </article> <article> <h1>Lesson 2: Enhanced HTTP Routing — Method patterns in net/http, no more gorilla/mux</h1> <p>Sun, 11 Aug 2024 00:00:00 +0000</p> <p>For most of my Go career, the standard library’s <code>net/http.ServeMux</code> was something I used for toy services and immediately replaced with <code>gorilla/mux</code> for anything real. The standard mux could not match HTTP methods. It could not extract path parameters. It matched prefixes in ways that surprised people. The moment a production service needed <code>GET /users/{id}</code> and <code>POST /users</code>, you reached for a dependency.</p> <p>Go 1.22 changed that. The enhanced <code>ServeMux</code> now supports method matching, wildcard path parameters, and precedence rules that actually make sense. I rewrote three internal services to drop <code>gorilla/mux</code> after reading the release notes, and every one of them got shorter and simpler. This lesson covers exactly what changed and when you still might want a third-party router.</p> </article> <article> <h1>Lesson 7: On-Call Engineering — Reducing toil, improving reliability</h1> <p>Sun, 11 Aug 2024 00:00:00 +0000</p> <p>I did 12 months of on-call on a team that hadn’t invested in reliability. The rotation was weekly. In a bad week, I’d get 15-20 pages. A good week was 5. I was exhausted by the end of my shift, and the paging frequency had barely changed over those 12 months. We were fixing incidents, not fixing the causes. The next team I joined approached on-call differently: on-call was treated as a reliability sensor, not a firefighting rotation. Pages were tracked, patterns identified, and root causes fixed. By month 6 I was averaging 2 pages per week on-call. The work we did during on-call made future on-call better.</p> </article> <article> <h1>Lesson 1: Unit Tests — #[test] and assertions</h1> <p>Sat, 10 Aug 2024 14:22:00 +0000</p> <p>I shipped a Rust library last year that had zero tests. Not because I’m lazy — I was prototyping, moving fast, “I’ll add tests later.” You know how that story ends. A one-character typo in a boundary check sat in production for three weeks before someone’s data got silently corrupted. Three weeks. I’d have caught it with one <code>assert_eq!</code> and thirty seconds of effort.</p> <p>Never again. Here’s how testing actually works in Rust, from the ground up.</p> </article> <article> <h1>Lesson 2: Docker for Go — Multi-stage builds that produce tiny images</h1> <p>Sat, 10 Aug 2024 00:00:00 +0000</p> <p>The first Dockerfile I wrote for a Go service produced a 1.2 GB image. It was based on <code>golang:1.22</code>, which includes the full Go toolchain, build cache, test infrastructure, and a complete Debian system. The compiled binary was 18 MB. I was shipping 1.2 GB to run 18 MB.</p> <p>The second version, after learning about multi-stage builds, produced a 22 MB image. Same binary. No compiler. No package manager. No shell. Just the binary and the absolute minimum needed to run it. The difference matters not just for storage: smaller images pull faster, have smaller attack surfaces, and fail more obviously when a required file is missing.</p> </article> <article> <h1>Lesson 8: Replication — Streaming, Logical, and Failover</h1> <p>Fri, 09 Aug 2024 00:00:00 +0000</p> <p>The first time I had to fail over a Postgres primary, it was 2 AM, the primary was not responding, and I genuinely did not know whether the replica was up to date or 10 minutes behind. We recovered, but that experience drove me to actually understand replication — not just “the replica gets the writes somehow” but exactly what data is shipped, when it arrives, and what happens when the primary dies. It turns out the mechanism is elegant and directly connected to the WAL we covered in Lesson 3.</p> </article> <article> <h1>Lesson 8: Refutable vs Irrefutable Patterns — Where they apply</h1> <p>Thu, 08 Aug 2024 12:40:00 +0000</p> <p>I remember the first time the Rust compiler told me “refutable pattern in local binding.” I stared at the error for five minutes, Googled “refutable pattern Rust,” read the explanation, and thought: “That’s… actually a really good distinction that no other language makes explicit.”</p> <p>Every pattern in Rust is either refutable or irrefutable. Understanding which is which — and where each is allowed — clears up a whole class of confusing compiler errors.</p> </article> <article> <h1>Lesson 3: Request Validation — Never trust the caller</h1> <p>Thu, 08 Aug 2024 00:00:00 +0000</p> <p>I once shipped an endpoint that accepted a <code>limit</code> query parameter for pagination. The valid range was 1–100. I did not validate it. Someone called it with <code>limit=-1</code> and my database query returned every row in the table. The query took 45 seconds and brought the service to its knees. The fix was a two-line bounds check that I should have written from the start.</p> <p>Validation is not optional. It is the contract between your API and the outside world.</p> </article> <article> <h1>Lesson 2: Deployments and Scaling — Rolling updates, HPA, VPA</h1> <p>Wed, 07 Aug 2024 00:00:00 +0000</p> <p>The week before a major product launch, our Kubernetes cluster started evicting pods. Traffic was spiking as we ran load tests, but instead of scaling up, the HPA was oscillating — scaling up, then the new pods were getting OOMKilled, then scaled down, then up again. Pods were in CrashLoopBackOff, the HPA metrics were lagging behind the actual load, and I was watching health check failures cascade. It turned out our resource requests were wildly inaccurate — set once during initial deployment and never updated as the service’s actual usage changed. That day I learned that Deployments and autoscaling aren’t fire-and-forget configurations.</p> </article> <article> <h1>Lesson 7: Migration Strategies — Strangler fig and feature flags</h1> <p>Wed, 07 Aug 2024 00:00:00 +0000</p> <p>Rewrites are seductive. The existing system is messy, it’s slow to change, and the new system in your head is clean and fast and well-designed. Then you start the rewrite. Six months in, you’ve rebuilt 40% of the functionality and the remaining 60% is more complex than you thought. Meanwhile, the old system keeps shipping features. The new system falls behind, gets cancelled, and you’re back where you started, except now you’ve lost six months and the team is demoralized. I’ve seen this happen twice. The third time, we used the strangler fig pattern instead, and it worked.</p> </article> <article> <h1>Lesson 9: Tries — Prefix matching, autocomplete, routing tables</h1> <p>Tue, 06 Aug 2024 00:00:00 +0000</p> <p>When you type “ath” into a search box and it suggests “atharva,” “athens,” and “athletics,” that’s a trie. When an IP packet arrives at a router and the router decides which interface to forward it to, that’s a trie (specifically a Patricia trie). When your web framework matches <code>/api/users/:id</code> against an incoming URL, the fast implementations use a trie.</p> <p>Tries (pronounced “try,” from “re<em>trie</em>val”) are specialized trees for string keys. They trade memory for speed in prefix-matching scenarios, and they make certain string operations fundamentally faster than any other structure.</p> </article> <article> <h1>Lesson 7: The Visitor Pattern via Enums — When trait objects won't cut it</h1> <p>Mon, 05 Aug 2024 20:15:00 +0000</p> <p>I spent a week once trying to make trait objects work for an AST walker. Every new operation meant a new trait, a new impl block for every node type, and a growing pile of boilerplate. When I rewrote the whole thing with an enum and match, the code shrank by 60% and got faster. Not every problem needs dynamic dispatch.</p> <h2 id="the-problem-open-vs-closed-hierarchies">The Problem: Open vs. Closed Hierarchies</h2> <p>In object-oriented languages, the visitor pattern exists because class hierarchies are “open” — anyone can add new subclasses, so you can’t write a switch over all possible types. You need double dispatch through interfaces.</p> </article> <article> <h1>Lesson 2: Config and Env Handling — Viper, envconfig, or just os.Getenv?</h1> <p>Mon, 05 Aug 2024 00:00:00 +0000</p> <p>Configuration is one of those problems that looks trivial until it is not. A single environment variable is three lines of code. A configuration file with overridable environment variables, sensible defaults, validation, and reload-on-signal is a project in itself. Knowing when to use each approach — raw <code>os.Getenv</code>, struct-based env decoding, or a full configuration library like Viper — is more about understanding the tradeoffs than about which library is “best.”</p> </article> <article> <h1>Lesson 8: Design a URL Shortener — The Classic, Done Properly</h1> <p>Sun, 04 Aug 2024 00:00:00 +0000</p> <p>The URL shortener is the “Hello World” of system design interviews. It appears deceptively simple: take a long URL, return a short one. But if you treat it superficially, you miss what the interviewer is actually testing: your ability to think through ID generation at scale, read-heavy caching, redirect semantics, analytics storage, and data modeling. Done well, the URL shortener problem touches nearly every fundamental we’ve covered so far.</p> <h2 id="the-core-concept">The Core Concept</h2> <p>A URL shortener has two primary operations:</p> </article> <article> <h1>Lesson 7: Service Mesh — Sidecar proxies and mTLS without code</h1> <p>Sat, 03 Aug 2024 00:00:00 +0000</p> <p>A team I worked with had seventeen microservices. Each service had its own implementation of retry logic, circuit breaking, timeout handling, and mutual TLS. Some used libraries, some rolled their own. When we needed to update the TLS certificate rotation policy, it touched eleven different code repositories, four different languages, and took two months. Then we introduced Linkerd and moved all of that to the infrastructure layer. The services still did their jobs. The networking became someone else’s problem — specifically, the platform team’s.</p> </article> <article> <h1>Lesson 6: State Machines with Enums — Compile-time guarantees</h1> <p>Fri, 02 Aug 2024 07:20:00 +0000</p> <p>Three years ago, I debugged a payment processing system where an order could go from “refunded” back to “shipped.” Nobody intended for that to happen. The state machine was implemented with a status string and a bunch of if/else checks scattered across eight files. One developer added a shortcut. Review missed it. Customers got refund emails followed by shipping confirmations.</p> <p>If the state machine had been in the type system, that shortcut wouldn’t have compiled.</p> </article> <article> <h1>Lesson 2: Feature Stores — Why feature engineering is 80% of ML</h1> <p>Fri, 02 Aug 2024 00:00:00 +0000</p> <p>There is a saying in machine learning that is so universally acknowledged it has become a cliché: 80% of the work in any ML project is feature engineering. I spent a long time thinking this referred to the cognitive labor — the domain expertise required to craft meaningful features. It does, in part. But the deeper meaning is operational. The 80% is not just about <em>what</em> features to build; it’s about <em>how</em> to compute them consistently, store them efficiently, retrieve them with sub-millisecond latency at serving time, and keep them synchronized between the training pipeline and the production system.</p> </article> <article> <h1>Lesson 8: Dynamic Programming Intuition — Memoization, not memorization</h1> <p>Fri, 02 Aug 2024 00:00:00 +0000</p> <p>Dynamic programming has an intimidating reputation. The name sounds academic, the problems in textbooks often involve sequences and matrices, and the “aha moment” is notoriously hard to force. I spent a long time treating DP as an interview preparation topic rather than a tool I would actually use. That changed when I built a pricing engine and realized I had been reimplementing DP badly — without knowing it — by computing the same values over and over in nested function calls.</p> </article> <article> <h1>Lesson 3: Integration Tests — Unit tests lie, integration tests prove</h1> <p>Thu, 01 Aug 2024 00:00:00 +0000</p> <p>Unit tests feel productive. You write a function, you write a test, everything goes green, and you merge. But unit tests exist in a bubble — a bubble where every dependency returns exactly what you told it to return. The real world doesn’t do that. Your database serializes a <code>time.Time</code> differently than you expect. Your HTTP client follows a redirect your mock never mentioned. Your message queue drops a message under backpressure that your fake queue cheerfully delivered. I’ve had unit test suites where every test passed and the feature didn’t work in staging. Integration tests are what close that gap.</p> </article> <article> <h1>Lesson 5: Enums Carrying Data — Modeling real domains</h1> <p>Tue, 30 Jul 2024 09:55:00 +0000</p> <p>The worst bug I ever shipped came from a <code>status</code> field that was a string. It could be “active”, “Active”, “ACTIVE”, “active “, or — my personal favorite — “acitve”. Six months of data with a typo nobody caught because strings don’t have a compiler checking them.</p> <p>Rust enums would have made that bug impossible.</p> <h2 id="the-problem-with-primitive-obsession">The Problem With Primitive Obsession</h2> <p>In most languages, developers reach for strings, integers, and booleans to represent domain concepts. A user’s role is a string. An order status is an integer. A payment method is… also a string. This is called “primitive obsession” and it’s responsible for an entire category of bugs:</p> </article> <article> <h1>Lesson 1: Building MCP Servers in Go — Give AI agents tools with the Model Context Protocol</h1> <p>Tue, 30 Jul 2024 00:00:00 +0000</p> <p>When Claude or another AI assistant needs to look up a database record, call an internal API, or read a file from your filesystem, it can’t do that on its own — it needs tools. The Model Context Protocol (MCP) is Anthropic’s open standard for giving AI agents exactly those tools. An MCP server is a small program you write that exposes tools via a JSON-RPC protocol; the AI client calls your server to invoke them. I find this genuinely exciting as a Go developer: Go’s concurrency model and fast startup time make it a natural fit for MCP servers.</p> </article> <article> <h1>Lesson 7: Containers from Scratch — Namespaces, Cgroups, What Docker Does</h1> <p>Mon, 29 Jul 2024 00:00:00 +0000</p> <p>I spent the first two years of my career using Docker without understanding what it was actually doing. I thought containers were a “lightweight VM” — some kind of virtualization. Then I read Liz Rice’s “Containers from Scratch” talk and wrote a 100-line container runtime in Go. Containers are not virtual machines. They are just Linux processes with restricted views of the system, implemented using two kernel features: namespaces and cgroups. Once you see how simple the underlying mechanism is, you understand exactly what Docker adds and why containers behave the way they do.</p> </article> <article> <h1>Lesson 10: Production Error Architecture — Logging, reporting, recovery</h1> <p>Sun, 28 Jul 2024 11:30:00 +0000</p> <p>I shipped a Rust service to production once with great error types, proper <code>Result</code> propagation, context chains — the whole nine yards. And then I couldn’t debug anything because every error got logged as a single flat string with no request ID, no trace correlation, and no distinction between “user sent bad input” and “our database is on fire.” Having good error <em>types</em> is half the battle. The other half is what you <em>do</em> with those errors when they reach the top of your stack.</p> </article> <article> <h1>Lesson 2: Metrics That Matter — Count, measure, alert</h1> <p>Sun, 28 Jul 2024 00:00:00 +0000</p> <p>The first metrics dashboard I built for a Go service had forty-two graphs. CPU, memory, goroutine count, heap allocations, GC pause duration, request rate, error rate, and about thirty-five other things that felt important when I added them. Six months later I was on call at 3 AM and the service was degraded. I opened that dashboard, looked at forty-two graphs, and had no idea where to start.</p> <p>Metrics are only useful when you know what to alert on, and you can only alert on things you understand. More metrics is not the same as better observability. The question is not “what can I measure?” but “what breaks, how do I know it’s broken, and how quickly can I narrow down why?”</p> </article> <article> <h1>Lesson 6: Feature Flags — Progressive rollout and kill switches</h1> <p>Sun, 28 Jul 2024 00:00:00 +0000</p> <p>We deployed a new checkout flow on a Friday afternoon. It had passed code review, passed testing, passed staging load tests. By Friday evening, the error rate was climbing. The new flow had a race condition that only manifested under specific mobile browser timing that we hadn’t tested. Without a feature flag, the fix would have required an emergency deployment — 25 minutes of build time, deployment, and validation. With a feature flag, the rollback was turning off a switch. Thirty seconds.</p> </article> <article> <h1>Lesson 4: Or Patterns, @ Bindings, and Rest Patterns — The full syntax</h1> <p>Sat, 27 Jul 2024 14:10:00 +0000</p> <p>I was reviewing a PR last year where someone had written twelve match arms for an enum — four groups of three variants that all did the same thing. Each group was identical code, copy-pasted three times. I left a one-line comment: “or patterns.” The whole match collapsed from 36 lines to 12.</p> <p>Most Rust developers learn the basics of <code>match</code> early and never dig into the full pattern syntax. That’s a shame, because there are three features that eliminate a ton of redundancy: or patterns, <code>@</code> bindings, and rest patterns.</p> </article> <article> <h1>Lesson 7: Connection Pooling — What PgBouncer Actually Does</h1> <p>Sat, 27 Jul 2024 00:00:00 +0000</p> <p>A Postgres connection is not cheap. When I first scaled a service from a single server to 20 replicas — each running a Go application with <code>database/sql</code>’s default pool settings — the database became the bottleneck almost immediately. Not because the queries were slow. Because we had 20 × 100 = 2,000 open connections, each consuming RAM on the Postgres server, and Postgres was spending more time managing connections than executing queries. This is the problem PgBouncer solves, and understanding how it works makes you a much better architect of backend systems.</p> </article> <article> <h1>Lesson 2: Raft Consensus — The consensus algorithm you can actually understand</h1> <p>Fri, 26 Jul 2024 00:00:00 +0000</p> <p>When I first tried to understand Paxos — the original distributed consensus algorithm — I read the paper three times and still felt like I was missing something. I could follow each step individually, but I couldn’t build a mental model of why it worked or what the invariants were. Raft was designed specifically to fix that. Its paper is literally titled “In Search of an Understandability: The Raft Consensus Algorithm.” After reading it, I could explain it to someone else. That’s the bar Raft was designed to clear, and it does.</p> </article> <article> <h1>Lesson 3: Match Guards and Bindings — Fine-grained control</h1> <p>Thu, 25 Jul 2024 08:30:00 +0000</p> <p>A few months back I was writing a rate limiter. The logic was simple: if the request is from an internal IP <em>and</em> the rate is under the limit, allow it. If it’s external <em>and</em> under a different limit, allow it. Otherwise, reject. I started with nested <code>if</code> statements inside match arms and ended up with something that looked like a plate of spaghetti. Then I rewrote it with match guards and the whole function collapsed to six clean lines.</p> </article> <article> <h1>Lesson 2: Giant God Structs — If your struct has 30 fields, it has 30 problems</h1> <p>Thu, 25 Jul 2024 00:00:00 +0000</p> <p>I inherited a Go service where the primary domain object was a struct with 47 fields. Some were database columns, some were computed from other fields, some were HTTP response projections, some were used only during a specific workflow stage, and a handful were there because someone once needed a flag and adding a field to the God struct was the path of least resistance. The struct was everywhere — passed between functions, serialized to JSON, written to the database, and used as a GraphQL response type. Every change to it rippled through the entire codebase.</p> </article> <article> <h1>Lesson 2: Parsing — Tokens to AST, recursive descent</h1> <p>Thu, 25 Jul 2024 00:00:00 +0000</p> <p>The lexer gave us tokens. The tokens are still flat — a sequence with no hierarchy. The expression <code>1 + 2 * 3</code> produces six tokens, but it does not yet say that <code>2 * 3</code> should be computed before adding <code>1</code>. That grouping, that hierarchy, is what the parser builds. By the time the parser is done, we have a tree. A specific kind of tree: an Abstract Syntax Tree, or AST. Everything after the parser works on this tree: evaluation, type checking, code generation, optimization. The tree is the program.</p> </article> <article> <h1>Lesson 9: panic!, unwrap, expect — When crashing is correct</h1> <p>Wed, 24 Jul 2024 07:55:00 +0000</p> <p>There’s a pervasive myth in the Rust community that <code>unwrap()</code> is always bad. I’ve seen code reviews where people mechanically replace every <code>unwrap()</code> with a <code>match</code> or <code>.expect()</code>, even when the <code>unwrap()</code> was perfectly correct. The truth is more nuanced: <code>panic!</code> is a tool, and like any tool, the question isn’t “should I ever use it?” but “when is it the right choice?”</p> <h2 id="what-panic-actually-does">What panic! Actually Does</h2> <p>When you call <code>panic!()</code>, Rust does one of two things depending on your configuration:</p> </article> <article> <h1>Lesson 2: Spotting Over-Abstraction — When your abstraction is the problem</h1> <p>Wed, 24 Jul 2024 00:00:00 +0000</p> <p>There’s a version of Go code I see in almost every codebase that’s been touched by developers who came from Java or C# — it’s covered in interfaces, repositories, factories, and service layers that all wrap exactly one concrete implementation. No tests mock these interfaces. No second implementation exists. The abstraction is doing nothing except adding indirection. I’ve written code like this myself, and the tell is always the same: when something breaks, I have to jump through five files to understand what happens when I call <code>CreateUser</code>.</p> </article> <article> <h1>Lesson 6: API Versioning — URL, header, or content negotiation</h1> <p>Wed, 24 Jul 2024 00:00:00 +0000</p> <p>The first time I shipped a breaking change to a production API without a version, I got an incident at 2am because a partner integration stopped working. They’d been calling <code>/api/orders</code> for six months. I changed the response shape. Their code broke. That was when “API versioning” moved from “thing to do eventually” to “thing to do before you ship anything external.”</p> <p>There’s no universally right answer to how you version APIs. There are tradeoffs, and the choice you make will shape your codebase for years. Here’s how I think about it.</p> </article> <article> <h1>Lesson 8: Graphs — You're solving graph problems without knowing it</h1> <p>Tue, 23 Jul 2024 00:00:00 +0000</p> <p>Most engineers don’t think of themselves as solving graph problems. They think they’re deploying microservices, resolving package dependencies, routing network traffic, or modeling social connections. But the underlying structure in all of these is a graph, and the algorithms that make those systems work — Dijkstra’s, topological sort, BFS, DFS — are graph algorithms.</p> <p>Once I started seeing graphs everywhere, I started solving systems problems better. Let me show you the representation, the key algorithms, and the production contexts where this thinking pays off.</p> </article> <article> <h1>Lesson 2: Destructuring — Structs, tuples, enums, nested</h1> <p>Mon, 22 Jul 2024 16:45:00 +0000</p> <p>I used to write code like <code>point.x</code>, <code>point.y</code>, <code>point.z</code> over and over in the same function. Three fields, three accesses, repeated twelve times. Then I learned destructuring and realized I’d been doing the equivalent of opening a package, looking at each item individually, and putting it back before looking at the next one.</p> <p>Destructuring is opening the package and grabbing everything at once.</p> <h2 id="the-problem-with-field-by-field-access">The Problem With Field-by-Field Access</h2> <p>When you work with compound types — structs, tuples, enums with data — you constantly need to pull values out of them. In most languages, this means dot access or method calls, and you end up with verbose code that obscures the actual logic:</p> </article> <article> <h1>Lesson 1: CGo Basics — When you need C and how to call it safely</h1> <p>Mon, 22 Jul 2024 00:00:00 +0000</p> <p>There is a saying in the Go community: “cgo is not Go.” It is not an insult. It is a warning. The moment you add <code>import "C"</code> to a file, you are no longer writing a pure Go program — you are writing a Go program that manages a C boundary, and all the things that make Go comfortable (fast builds, easy cross-compilation, the race detector, straightforward stack traces) become harder. You are doing it on purpose, because the alternative is worse.</p> </article> <article> <h1>Lesson 3: Good Patterns — Generic code should be boring</h1> <p>Mon, 22 Jul 2024 00:00:00 +0000</p> <p>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.</p> <p>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.</p> </article> <article> <h1>Lesson 8: Adding Context — Error chains and backtraces</h1> <p>Sun, 21 Jul 2024 13:10:00 +0000</p> <p>Picture this: it’s 2 AM, your pager goes off, and the log says <code>"connection refused"</code>. Connection to <em>what</em>? From <em>where</em>? During <em>which operation</em>? That single error message is technically correct and practically useless. I’ve been in that exact situation enough times to develop strong opinions about error context. Every error in a production system should answer three questions: what happened, where did it happen, and what was the system trying to do when it happened.</p> </article> <article> <h1>Lesson 7: Rate Limiting — Token Bucket, Sliding Window, Distributed</h1> <p>Sun, 21 Jul 2024 00:00:00 +0000</p> <p>Without rate limiting, a single misbehaving client can consume all your resources and deny service to everyone else. A bug in a client that retries in a tight loop. A competitor scraping your API. A DDoS attack. A feature that accidentally calls your endpoint ten times per button click. Rate limiting is the mechanism that prevents any of these from taking down your service — it’s the first line of defense between the internet and your origin.</p> </article> <article> <h1>Lesson 1: match — Exhaustive by design</h1> <p>Sat, 20 Jul 2024 11:23:00 +0000</p> <p>I shipped a Python service once that had a <code>match</code> statement handling four message types. Three months later, the team added a fifth type. Nobody updated the match. The default branch silently swallowed the new messages, and we lost two days of analytics data before anyone noticed.</p> <p>Rust’s <code>match</code> wouldn’t have let that happen.</p> <h2 id="the-problem-with-non-exhaustive-matching">The Problem With Non-Exhaustive Matching</h2> <p>Most languages treat pattern matching (or switch/case) as a convenience. You list the cases you care about, slap a default at the bottom, and move on. The problem is that code evolves. New variants get added, old assumptions break, and that default case quietly covers up bugs.</p> </article> <article> <h1>Lesson 2: Retries with Exponential Backoff — Retry right or retry forever</h1> <p>Sat, 20 Jul 2024 00:00:00 +0000</p> <p>I once worked on a service that retried failed HTTP requests in a tight loop with no backoff and no jitter. When our upstream had a brief outage, every instance of our service fired retries simultaneously, on the same cadence, forever. The upstream came back online, got immediately hammered by a synchronized retry storm from fifty instances, went down again, and the cycle repeated for forty minutes. The “retry” logic had turned a five-minute outage into a cascading failure.</p> </article> <article> <h1>Lesson 7: Shortest Path — Dijkstra in routing and network optimization</h1> <p>Fri, 19 Jul 2024 00:00:00 +0000</p> <p>When I joined a team building a multi-region traffic routing system, the first thing I had to understand was why the routing decisions were not always the geographically shortest path. The system was using Dijkstra’s algorithm, but the edge weights were not just latency — they incorporated bandwidth cost, current utilization, failure rates, and SLA constraints. Dijkstra did not care what the weights meant. It just found the minimum cost path. That is its power.</p> </article> <article> <h1>Lesson 7: Library vs Application Error Strategy — They're not the same</h1> <p>Thu, 18 Jul 2024 09:40:00 +0000</p> <p>I learned this the hard way. I was building a parsing library and used <code>anyhow::Error</code> as my error type in all public functions. A user opened an issue: “I can’t match on your errors to handle different parse failures differently.” They were right. I’d designed a library with application-level error handling, and it was a terrible experience for consumers. Took me a weekend to refactor everything to typed errors.</p> <p>Libraries and applications have fundamentally different error handling requirements. Mix them up and you’ll either frustrate your users or drown in unnecessary boilerplate.</p> </article> <article> <h1>Lesson 2: Nil Interface Gotchas — nil is not nil when it has a type</h1> <p>Thu, 18 Jul 2024 00:00:00 +0000</p> <p>A few months into my first production Go service, I had a bug that cost me two hours. A function returned an <code>error</code>, I checked <code>if err != nil</code> and it passed — but then further down the stack the program panicked trying to call <code>.Error()</code> on a nil pointer. The function had returned a nil <code>*MyError</code>, not a nil <code>error</code>. These are not the same thing, and until you internalize why, you will hit this bug.</p> </article> <article> <h1>Lesson 6: gRPC and Protobuf — Binary protocols and streaming</h1> <p>Wed, 17 Jul 2024 00:00:00 +0000</p> <p>The first JSON API I replaced with gRPC was passing <code>[]Order</code> objects around — each order had about 40 fields, most of which the caller never used. The JSON payload for a list of 100 orders was around 180KB. After the migration it was 22KB, and the serialization time in benchmarks dropped by 8x. But more than the performance numbers, what I noticed was the schema. Proto files are contracts. When a field changes, you know it. With JSON, you find out when things break in production.</p> </article> <article> <h1>Lesson 6: anyhow — When you don't care about the type</h1> <p>Tue, 16 Jul 2024 16:20:00 +0000</p> <p>There’s a dirty secret in Rust error handling: half the time, you don’t actually need typed errors. You need errors that are easy to create, easy to chain, and easy to print. That’s <code>anyhow</code>. Same author as <code>thiserror</code> (David Tolnay), completely different use case. Where <code>thiserror</code> is for defining precise error types, <code>anyhow</code> is for <em>using</em> errors without ceremony.</p> <h2 id="the-problem-anyhow-solves">The Problem anyhow Solves</h2> <p>Without <code>anyhow</code>, when you have a function that can fail in multiple unrelated ways, you either:</p> </article> <article> <h1>Lesson 2: Stack vs Heap Intuition — The allocation you didn't know you made</h1> <p>Tue, 16 Jul 2024 00:00:00 +0000</p> <p>There’s a class of performance bugs in Go that doesn’t show up in code review, doesn’t trigger the race detector, and doesn’t cause test failures. It just makes your service slowly worse under load. The source is almost always the same: heap allocations happening in places you didn’t intend, turning what should be fast stack operations into GC-visible objects that pile up until the collector has to stop and clean them up. Building an intuition for when Go allocates on the heap versus the stack was one of the single highest-leverage things I did to improve the services I work on.</p> </article> <article> <h1>Lesson 2: Consumer-Side Interfaces — Define where you use, not where you build</h1> <p>Mon, 15 Jul 2024 00:00:00 +0000</p> <p>There is a convention I spent a long time following without questioning it: put the interface in the same package as the type that implements it. If I had a <code>payment</code> package with a <code>Stripe</code> struct, I would also define <code>PaymentProcessor</code> right there. Callers would import <code>payment.PaymentProcessor</code>. It felt natural — the interface lives next to the thing it describes.</p> <p>Go’s designers had a different idea in mind, and it took me several refactoring sessions on a real codebase before I understood why it matters: interfaces should be defined by the package that uses them, not the package that implements them. The Go standard library does this consistently and for good reason.</p> </article> <article> <h1>Lesson 3: Design Google Docs — Real-time collaboration, OT vs CRDT, conflict resolution</h1> <p>Mon, 15 Jul 2024 00:00:00 +0000</p> <p>Google Docs is the problem I recommend to every engineer who thinks they understand distributed systems. The surface looks trivial: multiple users editing a document simultaneously. The depth is staggering. When two users type at the same position in a document at the same millisecond, what does each user see? How do you converge on a consistent state without a central lock? How do you preserve the intention behind each edit, not just the characters?</p> </article> <article> <h1>Lesson 5: thiserror — Derive your way to clean errors</h1> <p>Sun, 14 Jul 2024 10:00:00 +0000</p> <p>After writing my third custom error type by hand — with the <code>Display</code> impl, the <code>Error</code> impl, the <code>From</code> impls — I thought, “there has to be a better way.” There was. It’s called <code>thiserror</code>, and it’s probably the most widely-used error handling crate in the Rust ecosystem. David Tolnay wrote it, which means it’s well-designed, well-maintained, and does exactly one thing with zero bloat.</p> <h2 id="what-thiserror-does">What thiserror Does</h2> <p><code>thiserror</code> is a derive macro that generates <code>Display</code>, <code>Error</code>, and <code>From</code> implementations for your error types. It produces the exact same code you’d write by hand — no runtime cost, no extra dependencies at runtime (it’s a proc-macro, so it’s only a compile-time dependency).</p> </article> <article> <h1>Lesson 6: Signals — SIGTERM vs SIGKILL and Graceful Shutdown</h1> <p>Sun, 14 Jul 2024 00:00:00 +0000</p> <p>The first time I deployed a service to Kubernetes and watched it restart, I noticed that requests in flight were sometimes failing with connection resets. The pod was receiving 502 responses for a few seconds before it disappeared. I had heard of “graceful shutdown” but hadn’t implemented it. Kubernetes sends <code>SIGTERM</code> before killing a process, giving it time to finish in-flight requests — but my service was either ignoring the signal or exiting immediately, cutting off connections mid-request. Learning how signals work at the OS level, and then implementing correct signal handling in Go, fixed the issue permanently.</p> </article> <article> <h1>Lesson 5: Load Testing — k6, vegeta, realistic patterns</h1> <p>Sat, 13 Jul 2024 00:00:00 +0000</p> <p>We load-tested our new checkout service before launch. 1,000 virtual users, 10 minutes, all hitting <code>/v1/checkout</code> sequentially. It passed with excellent numbers. Launch day: real traffic hit the service, and it fell over at 200 concurrent users. The problem was our test. Real users don’t all call the same endpoint in sequence. They browse, add to cart, apply discount codes, fill in addresses, and then checkout — a session that touches 8 different endpoints over 4 minutes. Our test didn’t model this. Our test was measuring the wrong thing.</p> </article> <article> <h1>Lesson 15: GATs — Generic associated types explained</h1> <p>Fri, 12 Jul 2024 18:00:00 +0000</p> <p>GATs (Generic Associated Types) took <em>seven years</em> 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.</p> <p>The one-liner: GATs let associated types have their own generic parameters, including lifetimes.</p> </article> <article> <h1>Lesson 1: WASM from Go — Compile Go to WebAssembly and run it anywhere</h1> <p>Fri, 12 Jul 2024 00:00:00 +0000</p> <p>I came to WebAssembly skeptically. The pitch — “run code anywhere, at near-native speed, in a sandboxed environment” — sounded like the kind of claim that looks great in a conference talk and falls apart in production. It took a specific use case to make me take it seriously: I needed to run the same validation logic in three environments — a Go backend, a JavaScript frontend, and a CLI tool — without maintaining three separate implementations of the same business rules.</p> </article> <article> <h1>Lesson 2: Avoiding Cyclic Dependencies — If packages import each other, your design is wrong</h1> <p>Fri, 12 Jul 2024 00:00:00 +0000</p> <p>The Go compiler refuses to build a program with a cyclic import. It is not a warning. It is not a lint violation. It is a hard failure. I used to find this annoying when I was newer to the language. Now I consider it one of Go’s greatest gifts. The compiler is telling you something important: if package A needs package B and package B needs package A, you have not yet understood what the relationship between these two concepts really is.</p> </article> <article> <h1>Lesson 4: Designing Custom Error Types — Your domain, your errors</h1> <p>Thu, 11 Jul 2024 19:15:00 +0000</p> <p>I once worked on a project where every error was <code>Box<dyn std::error::Error></code>. Debugging was miserable. When something failed in production, the logs said things like “invalid input” with zero context about <em>which</em> input, <em>where</em> in the pipeline, or <em>why</em> it was invalid. That’s when I learned that good error types aren’t an afterthought — they’re part of your domain model.</p> <h2 id="why-custom-error-types-matter">Why Custom Error Types Matter</h2> <p>Standard library errors like <code>io::Error</code> and <code>ParseIntError</code> are fine for what they describe. But your application has its own failure modes. A payment processor doesn’t just fail with “IO error” — it fails with “card declined,” “insufficient funds,” “gateway timeout,” “idempotency key conflict.” These are domain-specific failures that deserve domain-specific types.</p> </article> <article> <h1>Lesson 6: Query Planning and EXPLAIN — Reading Execution Plans</h1> <p>Thu, 11 Jul 2024 00:00:00 +0000</p> <p>The first time I ran <code>EXPLAIN ANALYZE</code> on a slow query, I stared at the output for five minutes and understood none of it. It looked like a compiler error message crossed with a financial report. Then a senior engineer walked me through it, and what had looked like noise resolved into a clear picture: this node was doing more work than the planner expected, this join strategy was wrong, this sort was spilling to disk. <code>EXPLAIN ANALYZE</code> is the most powerful tool in database performance work, and it takes an hour to learn but pays back every week for the rest of your career.</p> </article> <article> <h1>Lesson 14: Const Generics — Types parameterized by values</h1> <p>Wed, 10 Jul 2024 15:30:00 +0000</p> <p>Before const generics landed (Rust 1.51), working with arrays was painful. You couldn’t write a function that accepted <code>[T; N]</code> for any <code>N</code>. The standard library had trait implementations for arrays up to size 32 — manually written, one per size. Need <code>[u8; 33]</code> to implement <code>Debug</code>? Too bad. That era is over, and honestly, const generics are one of the most underappreciated features in modern Rust.</p> <p>Instead of parameterizing types by <em>other types</em>, you parameterize them by <em>values</em>. An array’s size, a buffer’s capacity, a matrix’s dimensions — baked into the type system at compile time.</p> </article> <article> <h1>Lesson 2: Fuzzing in Go — Let the machine find your edge cases</h1> <p>Wed, 10 Jul 2024 00:00:00 +0000</p> <p>There’s a class of bugs that you will never find by thinking about edge cases. You’ll think about empty strings, about zero values, about negative numbers. But will you think about the string that’s exactly 65,536 bytes? Or the UTF-8 sequence that’s technically valid but trips up a specific parser codepath? Or the floating point value that serializes and then fails to deserialize because of a precision edge in your JSON handling? You won’t. But a fuzzer will find it in under a minute.</p> </article> <article> <h1>Lesson 3: The ? Operator — Propagation made elegant</h1> <p>Tue, 09 Jul 2024 14:30:00 +0000</p> <p>Before the <code>?</code> operator existed, Rust had <code>try!()</code> — a macro that did the same thing but looked ugly and nested poorly. When <code>?</code> landed in Rust 1.13, it was one of those rare language changes where everyone immediately agreed it was better. I remember refactoring an entire crate the same week, deleting dozens of <code>match</code> blocks and <code>try!()</code> calls, and the code just… breathed.</p> <h2 id="what--actually-does">What ? Actually Does</h2> <p>The <code>?</code> operator is syntactic sugar for early return on error. When you write this:</p> </article> <article> <h1>Lesson 7: Heaps and Priority Queues — Scheduling, top-K, and rate limiters</h1> <p>Tue, 09 Jul 2024 00:00:00 +0000</p> <p>Every time your operating system picks the next process to run, it’s using a heap. Every time Kubernetes re-schedules a pod, it’s using a priority queue. Every time you’ve written a “get top 10 most frequent items from a billion-row stream,” the efficient solution involves a heap. These are workhorses of systems programming that look simple on paper and have genuinely tricky implementation details.</p> <p>The heap is also one of my favorite data structures to explain because it demonstrates a beautiful property: you can implement a tree efficiently inside an array, using only arithmetic to find parent and child nodes.</p> </article> <article> <h1>Lesson 2: Secret Handling — Env vars are not a vault</h1> <p>Mon, 08 Jul 2024 00:00:00 +0000</p> <p>I once found database credentials committed directly in a Go source file — not in a toy project, in a staging environment of a real product. The developer who wrote it knew it was wrong, but they were “just testing” and forgot to revert it. That file lived in the repository for eight months before anyone noticed. By then, the credentials had been rotated, but the history was permanent.</p> <p>Secret handling in Go is not primarily a coding problem. It is a discipline problem. The code patterns are simple. The failures happen when you treat secrets as a detail to clean up later, or when you assume that environment variables are inherently safe because they are not in source code.</p> </article> <article> <h1>Lesson 13: Monomorphization — How generics become fast</h1> <p>Sun, 07 Jul 2024 11:45:00 +0000</p> <p>“Zero-cost abstractions” is Rust’s battle cry. But what does that actually mean for generics? How does <code>Vec<i32></code> and <code>Vec<String></code> 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.</p> <p>This is brilliant. It’s also a double-edged sword. And understanding the mechanism changes how you design generic APIs.</p> </article> <article> <h1>Lesson 2: Result and Option — The foundation</h1> <p>Sun, 07 Jul 2024 08:45:00 +0000</p> <p>When I first started writing Rust, I used <code>match</code> on every single <code>Result</code> and <code>Option</code>. My code looked like a staircase — match inside match inside match, indented halfway across the screen. Then a colleague showed me combinators, and suddenly the code read like prose instead of a tax form.</p> <h2 id="result-more-than-just-ok-and-err">Result: More Than Just Ok and Err</h2> <p>You already know <code>Result<T, E></code> has two variants. But <code>Result</code> comes with a <em>huge</em> set of methods that let you transform, combine, and short-circuit without writing explicit <code>match</code> blocks everywhere.</p> </article> <article> <h1>Lesson 5: DDD Essentials — Bounded contexts and aggregates</h1> <p>Sun, 07 Jul 2024 00:00:00 +0000</p> <p>The concept of “customer” meant something different in every team I talked to at one company. To the billing team, a customer was a billing account. To the support team, a customer was a person who filed tickets. To the identity team, a customer was an authenticated principal. Every team had their own <code>Customer</code> struct, and syncing them was a full-time job. That’s the problem DDD’s bounded context concept solves — and it’s one of those ideas that sounds academic until you’ve suffered without it.</p> </article> <article> <h1>Lesson 1: Service Boundaries — Split by business capability, not by technical layer</h1> <p>Sat, 06 Jul 2024 00:00:00 +0000</p> <p>The most expensive architectural mistake I’ve seen teams make with microservices is splitting by technical layer instead of by business capability. I’ve seen systems with a “UserDataService,” a “UserLogicService,” and a “UserNotificationService” — three services that all have to be deployed together for any user-related feature to work, that share a database, and that call each other synchronously for every request. They’re not microservices; they’re a distributed monolith with extra network latency.</p> </article> <article> <h1>Lesson 1: Rust's Error Philosophy — No exceptions, no surprises</h1> <p>Fri, 05 Jul 2024 11:23:00 +0000</p> <p>I spent three years writing Java before I touched Rust. In Java, any function call might throw an exception — checked, unchecked, runtime, whatever. You never really <em>know</em> what’s going to blow up until it does. The first time I wrote Rust code that forced me to handle every possible failure at the call site, I thought it was annoying. Six months later, I realized it was the sanest approach to errors I’d ever used.</p> </article> <article> <h1>Lesson 2: Middleware Patterns — Wrap the handler, not the logic</h1> <p>Fri, 05 Jul 2024 00:00:00 +0000</p> <p>The first time I wrote authentication logic, I put it directly inside each handler. Copy-paste, then copy-paste again. By handler number five I had four slightly different versions of the same JWT check scattered across the codebase. When the security team asked me to add a new validation step, I had to find and update every single one. That was the day I understood middleware.</p> <h2 id="the-problem">The Problem</h2> <p>Business logic in a handler should answer one question: “What does this endpoint do?” But handlers inevitably accumulate cross-cutting concerns — logging, authentication, rate limiting, request ID injection, panic recovery. When these live inside the handler body, every handler becomes a tangle of concerns that are hard to test, hard to change, and impossible to apply consistently.</p> </article> <article> <h1>Lesson 12: Operator Overloading with Traits — Making your types feel native</h1> <p>Thu, 04 Jul 2024 20:15:00 +0000</p> <p>I was building a linear algebra library and got tired of writing <code>vector_a.add(&vector_b)</code> everywhere. It looked ugly. It read poorly. Math should look like math — <code>a + b</code>, not <code>a.add(&b)</code>. In Rust, operator overloading isn’t some dark magic — it’s just trait implementation. Every operator maps to a trait in <code>std::ops</code>, and implementing that trait makes the operator work on your type.</p> <h2 id="the-add-trait">The <code>Add</code> Trait</h2> <p>The <code>+</code> operator desugars to a call to <code>Add::add</code>:</p> </article> <article> <h1>Lesson 6: CDNs — Put Your Bytes Close to Your Users</h1> <p>Thu, 04 Jul 2024 00:00:00 +0000</p> <p>Physics is the enemy of performance. Light travels through fiber optic cables at about 200,000 km/s — roughly two-thirds the speed of light in a vacuum. A round-trip from New York to London is about 11,000 km each way. That means the minimum possible latency for that trip is 55ms. You cannot engineer your way past it. What you can do is stop making the trip at all. Content Delivery Networks are the infrastructure that puts popular content at the edge — closer to users, so the bytes never have to travel far.</p> </article> <article> <h1>Lesson 6: BFS and DFS — Dependency resolution, crawlers, cycle detection</h1> <p>Wed, 03 Jul 2024 00:00:00 +0000</p> <p>Graph traversal sounds abstract until you realize that most interesting data in production is a graph. Service dependencies are a graph. Database foreign key relationships form a graph. Build tool dependencies, org charts, permission hierarchies, network topologies — all graphs. BFS and DFS are the two fundamental ways to walk them, and they show up in real engineering work more than almost any other algorithm.</p> <p>I have used DFS to detect circular imports in a build system, BFS to find the shortest migration path between two schema versions, and both to debug why a dependency injection container was resolving services in the wrong order.</p> </article> <article> <h1>Lesson 11: Essential Std Traits — Iterator, Display, From, Default</h1> <p>Tue, 02 Jul 2024 08:30:00 +0000</p> <p>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 — <code>Display</code>, <code>From</code>, <code>Default</code>, <code>Iterator</code>. 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.</p> </article> <article> <h1>Lesson 1: net/http Deep Dive — The most important package you use wrong</h1> <p>Tue, 02 Jul 2024 00:00:00 +0000</p> <p>Every Go web service I’ve reviewed starts with <code>net/http</code>. Most of them use it correctly for the obvious parts and incorrectly for the subtle ones. The package API is deceptively simple — <code>http.HandleFunc</code>, <code>http.ListenAndServe</code>, and you’re serving HTTP. But the design decisions underneath — how request routing works, what a <code>Handler</code> actually is, how the server manages connections, what the default timeouts are — contain enough traps to keep a senior engineer busy for a week.</p> </article> <article> <h1>Lesson 2: Type Parameters and Constraints — Teaching the compiler what you mean</h1> <p>Mon, 01 Jul 2024 00:00:00 +0000</p> <p>The hardest part of learning Go generics isn’t the concept — it’s the syntax. The first time I read a function signature like <code>func Keys[K comparable, V any](m map[K]V) []K</code>, 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.</p> <p>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.”</p> </article> <article> <h1>Lesson 5: WebSockets — Upgrade, framing, vs SSE vs polling</h1> <p>Mon, 01 Jul 2024 00:00:00 +0000</p> <p>When I first built a real-time notification system, I reached for WebSockets because that’s what everyone said to use for “real-time.” Three months later I was debugging connection drops under load, wrestling with proxy timeouts, and fighting with nginx configuration. When I stepped back and actually thought about the access pattern — server pushing notifications to the browser, never the browser sending data to the server — I replaced WebSockets with Server-Sent Events in a weekend. The code got simpler, the proxies stopped complaining, and we had less to maintain. Picking the right tool requires understanding what each one actually does.</p> </article> <article> <h1>Lesson 10: Orphan Rules and the Newtype Workaround — Coherence in practice</h1> <p>Sun, 30 Jun 2024 17:55:00 +0000</p> <p>Picture this: you’re using two crates — <code>serde</code> and some <code>db_client</code> crate. You want to implement <code>serde::Serialize</code> for <code>db_client::Row</code>. Sounds reasonable. You write the <code>impl</code>, 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.</p> <p>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.”</p> </article> <article> <h1>Lesson 1: Static Binaries — One file, zero dependencies, deploy anywhere</h1> <p>Sun, 30 Jun 2024 00:00:00 +0000</p> <p>The first time I deployed a Go binary to a production server, I was braced for the usual ceremony: SSH in, install the right runtime version, copy over config files, fiddle with symlinks. Instead, I ran <code>scp</code> and then the binary, and it just worked. No installation. No dependency hell. No “but it works on my machine.” The binary contained everything it needed.</p> <p>This is Go’s single greatest operational advantage: the compiler produces a self-contained executable. Understanding exactly how this works — and how it can break — makes the difference between a deploy that takes five minutes and one that takes an afternoon.</p> </article> <article> <h1>Lesson 1: Event Store Design — Append-only logs that are your source of truth</h1> <p>Sat, 29 Jun 2024 00:00:00 +0000</p> <p>My first encounter with event sourcing was a financial system that needed a complete audit trail. The business requirement was clear: every change to an account balance had to be traceable — who changed it, when, why. The first approach was an audit log table alongside the main accounts table. We’d write to both in a transaction. Within six months, the audit table was out of sync with the accounts table. Bugs in the dual-write logic, a migration that updated account records without touching the audit log, a direct database fix that bypassed the application layer. The audit log was nearly useless. The core insight I eventually arrived at: the audit log shouldn’t be a secondary record — it should be the primary record. That’s event sourcing.</p> </article> <article> <h1>Lesson 9: Blanket Implementations — Implementing for all T</h1> <p>Fri, 28 Jun 2024 10:20:00 +0000</p> <p>The moment blanket implementations clicked for me, I felt like I’d been handed a cheat code. You write <code>impl<T: Display> ToString for T</code> and suddenly <em>every single type</em> that implements <code>Display</code> automatically gets <code>ToString</code>. One line of implementation logic, infinite types covered. This is how the standard library builds massive capability trees from small pieces.</p> <h2 id="whats-a-blanket-implementation">What’s a Blanket Implementation?</h2> <p>A blanket implementation implements a trait for all types matching a bound, rather than for a specific type:</p> </article> <article> <h1>Lesson 1: When Reflection Is Justified — The last resort that sometimes is the only resort</h1> <p>Fri, 28 Jun 2024 00:00:00 +0000</p> <p>Go’s <code>reflect</code> package carries a reputation: “don’t use it unless you have to.” That advice is correct but incomplete. Understanding <em>when</em> you actually have to use it — and when you are just reaching for it out of habit from dynamic languages — is the difference between reflection that pulls its weight and reflection that creates unmaintainable, slow, panic-prone code that confuses every future reader of the codebase.</p> <p>Reflection lets Go inspect and manipulate values, types, and struct fields at runtime without static type information. It is the mechanism behind <code>encoding/json</code>, <code>database/sql</code>’s row scanning, struct validators, ORM frameworks, and dependency injection containers. It is also the mechanism behind a lot of code that should have just used a map or an interface.</p> </article> <article> <h1>Lesson 5: Epoll and IO Multiplexing — How Go''s Netpoller Works</h1> <p>Thu, 27 Jun 2024 00:00:00 +0000</p> <p>I used to wonder how a Go HTTP server could handle 100,000 concurrent connections with only 8 OS threads. If each connection required a dedicated thread, you would need 100,000 threads — which would require roughly 800 GB of stack space and would spend all their time in the kernel scheduler. The answer is epoll: a Linux kernel interface that lets a single thread wait on thousands of file descriptors simultaneously and be notified only when one is ready for I/O. Go’s runtime uses epoll internally as the foundation of its network I/O model. This lesson explains how.</p> </article> <article> <h1>Lesson 6: B-Trees and B+ Trees — How every database index actually works</h1> <p>Wed, 26 Jun 2024 00:00:00 +0000</p> <p>Every time PostgreSQL, MySQL, SQLite, or MongoDB uses an index, it’s almost certainly a B-tree or B+ tree underneath. Not a binary search tree — a B-tree. The difference matters more than most engineers realize, and it comes down to one thing: disk read costs.</p> <p>I’ve seen engineers add indexes blindly to fix slow queries without understanding what an index actually is. When you understand B-trees, you understand why some indexes help more than others, why certain query patterns can’t use indexes, and why index-heavy tables slow down on writes.</p> </article> <article> <h1>Lesson 8: Object Safety — Why some traits can't be dyn</h1> <p>Tue, 25 Jun 2024 13:40:00 +0000</p> <p>The first time I got the error “the trait <code>Clone</code> 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 <code>dyn</code>? The answer is <em>object safety</em> — 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 <em>why</em> the rules exist.</p> </article> <article> <h1>Lesson 1: Structured Logging with slog — Printf is not observability</h1> <p>Tue, 25 Jun 2024 00:00:00 +0000</p> <p>I spent two years writing Go services that logged like this:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-go" data-lang="go"><span style="display:flex;"><span><span style="color:#a6e22e">log</span>.<span style="color:#a6e22e">Printf</span>(<span style="color:#e6db74">"processing order %s for user %d, amount %.2f"</span>, <span style="color:#a6e22e">orderID</span>, <span style="color:#a6e22e">userID</span>, <span style="color:#a6e22e">amount</span>) </span></span></code></pre></div><p>It worked fine — until the day I needed to find every failed payment over $500 from a specific user across three weeks of logs in a production incident at 2 AM. I was grepping through gigabytes of text, trying to parse freeform strings with jq, getting nowhere. The logs existed. The information was technically there. But I couldn’t <em>query</em> it in any meaningful way.</p> </article> <article> <h1>Lesson 4: Monitoring and Alerting — SLOs and alert fatigue</h1> <p>Mon, 24 Jun 2024 00:00:00 +0000</p> <p>The on-call rotation I inherited had 47 active alerts. On a bad week, the on-call engineer got paged 30 times. Most pages were “something might be wrong” noise — high CPU on one instance, a spike in error rate that self-resolved in 30 seconds, disk space at 70% on a server with months of capacity remaining. Engineers stopped taking the pages seriously. Then the one real incident got buried in the noise, and we had a 4-hour outage because no one treated the first alert seriously. Alert fatigue is not a monitoring problem. It’s an architecture-of-trust problem.</p> </article> <article> <h1>Lesson 7: dyn Trait — Runtime polymorphism and its cost</h1> <p>Sun, 23 Jun 2024 19:15:00 +0000</p> <p>Every Rust programmer hits this wall eventually. You have a <code>Vec</code> and you want to put different types in it — all implementing the same trait, but different concrete types. You try <code>Vec<impl Trait></code> and the compiler says no. You try <code>Vec<T></code> with generics and realize <code>T</code> can only be one type at a time. That’s when you discover <code>dyn Trait</code>, and the first real tradeoff in Rust’s type system: static dispatch vs dynamic dispatch.</p> </article> <article> <h1>Lesson 5: Transaction Isolation — Read Committed vs Serializable</h1> <p>Sun, 23 Jun 2024 00:00:00 +0000</p> <p>I shipped a bug once that allowed a user to spend the same gift card balance twice. Two requests arrived nearly simultaneously, both read the same balance, both decided the balance was sufficient, both deducted it, and both succeeded. The database did exactly what I asked. The problem was what I asked for: I assumed reads were consistent across statements within a transaction, but I was running at the default isolation level. Understanding the four isolation levels — and what each one actually protects you from — is not academic. It is the difference between shipping correct financial code and shipping race conditions.</p> </article> <article> <h1>Lesson 1: Building CLIs with Cobra — From main.go to production CLI</h1> <p>Sat, 22 Jun 2024 00:00:00 +0000</p> <p>Every Go project that grows into something useful eventually needs a command-line interface. Maybe it starts as a quick <code>main.go</code> with <code>os.Args[1]</code> checks and a switch statement. That works until you need subcommands, flags, help text, shell completion, and version information — and suddenly you are maintaining a hand-rolled argument parser that nobody wants to touch. Cobra is the standard library-grade solution to this problem, and learning to structure a Cobra application properly saves you from rewriting it twice.</p> </article> <article> <h1>Lesson 6: Supertraits — Building trait hierarchies</h1> <p>Fri, 21 Jun 2024 08:50:00 +0000</p> <p>I had a trait called <code>Serialize</code> (homebrew, pre-serde days) that needed to format things as strings. I kept calling <code>.to_string()</code> inside default methods and wondering why the compiler complained. The type implementing my trait didn’t necessarily implement <code>Display</code>. The fix was obvious in hindsight — make <code>Display</code> a <em>supertrait</em> of <code>Serialize</code>. If you want to serialize, you must be displayable. Period.</p> <p>Supertraits let you build trait hierarchies where implementing one trait <em>requires</em> implementing another.</p> </article> <article> <h1>Lesson 4: CQRS — When reads and writes need different models</h1> <p>Fri, 21 Jun 2024 00:00:00 +0000</p> <p>I maintained an e-commerce admin dashboard that had a query so complex it took 12 seconds to run. It joined seven tables across the orders, inventory, and customers domains to build a summary view of “all orders pending fulfillment, with customer tier, item details, and warehouse stock levels.” Every time the admin loaded the page, twelve seconds. We tried indexes, caching, materialized views — all helped at the margins. The fundamental problem was that we were asking our write-optimized relational model to answer a read-optimized reporting question. Separating the read model was the only real fix.</p> </article> <article> <h1>Lesson 1: Escape Analysis — Where your data lives matters more than how you write it</h1> <p>Thu, 20 Jun 2024 00:00:00 +0000</p> <p>I spent the first two years of writing Go completely unaware that the compiler was making decisions about my code that I never asked for — and that those decisions were quietly shaping the performance profile of everything I shipped. Escape analysis is the mechanism behind all of it. Once I understood it, I started reading code differently. Not just “does this work?” but “where does this data live, and did I give the compiler a chance to put it somewhere fast?”</p> </article> <article> <h1>Lesson 5: Associated Types vs Generic Parameters — Choosing the right tool</h1> <p>Wed, 19 Jun 2024 16:05:00 +0000</p> <p>Here’s a question that confused me for months: why does <code>Iterator</code> use an associated type (<code>type Item</code>) instead of a generic parameter (<code>Iterator<T></code>)? 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.</p> <p>The short answer: associated types mean “one implementation per type,” generic parameters mean “many implementations per type.” But the implications are deeper than that.</p> </article> <article> <h1>Lesson 5: Message Queues — Decoupling Services Without Losing Messages</h1> <p>Wed, 19 Jun 2024 00:00:00 +0000</p> <p>Synchronous calls are elegant until they’re not. Service A calls Service B. B is slow. A waits. A’s request pool fills up. A becomes slow. The caller of A waits. The whole request chain stalls. Add a few more services in the chain and you have a distributed deadlock in slow motion. Message queues exist to break this dependency — to let a producer say “here’s some work” and move on, without caring whether the consumer is fast, slow, or temporarily down.</p> </article> <article> <h1>Lesson 15: When You're Fighting the Borrow Checker — Restructure, Don't Hack</h1> <p>Tue, 18 Jun 2024 12:38:00 +0000</p> <p>Every Rust developer has been there. You’re implementing something that feels simple. It works in your head. But the borrow checker says no. You try different approaches. More errors. You start adding <code>.clone()</code> everywhere. You wrap things in <code>Rc<RefCell<...>></code>. You consider <code>unsafe</code>.</p> <p>Stop. Take a breath. The borrow checker isn’t wrong — your data flow is confused. And there’s almost always a clean restructuring that makes the error disappear.</p> <p>This lesson is a field guide. Real patterns that fight the borrow checker, and the restructurings that fix them.</p> </article> <article> <h1>Lesson 1: Interface Everywhere Syndrome — Not every dependency needs an interface</h1> <p>Tue, 18 Jun 2024 00:00:00 +0000</p> <p>When I came to Go from a Java background, I brought some habits with me that made my code worse, not better. The most persistent one was defining an interface for every dependency, regardless of whether there was any realistic chance of substituting an alternative implementation. I wrote <code>UserRepositoryInterface</code>, <code>EmailSenderInterface</code>, <code>LoggerInterface</code> — an entire shadow type system that mirrored every concrete type in the codebase. Every file had a corresponding interface file. The codebase was twice as large as it needed to be and no easier to test.</p> </article> <article> <h1>Lesson 4: where Clauses — When bounds get complex</h1> <p>Mon, 17 Jun 2024 11:30:00 +0000</p> <p>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 <code>Hash + Eq + Clone + Debug</code> on the key, <code>Serialize + DeserializeOwned + Clone</code> on the value, and <code>Display</code> on both. The inline bounds turned my function signature into an unreadable mess.</p> </article> <article> <h1>Lesson 5: Hashing and Consistent Hashing — How load balancers distribute traffic</h1> <p>Mon, 17 Jun 2024 00:00:00 +0000</p> <p>I did not think much about hashing until I had to explain why a cache cluster was unusable after we added two new nodes. We had doubled the cache hit rate over six months, added two boxes to handle the load, and immediately destroyed most of our cached data. Every key rehashed to a different server. Cache hit rate dropped from 85% to under 10%. We were hammering the database.</p> </article> <article> <h1>Lesson 1: Refactoring Go Code Safely — Change structure without changing behavior</h1> <p>Sun, 16 Jun 2024 00:00:00 +0000</p> <p>Refactoring is the one activity that makes codebases better without adding features — and it’s also the activity most likely to introduce bugs if done carelessly. I learned this the hard way on a payments service where I renamed a function, ran the tests, saw green, deployed, and watched a webhook handler silently stop processing because it had been calling the old function name through a string-based registry I hadn’t touched. The tests were green because the old function still existed — I just hadn’t deleted it yet. The refactor was correct; the process was not.</p> </article> <article> <h1>Lesson 1: Subtests and t.Run — Name your test cases or debug blind</h1> <p>Sat, 15 Jun 2024 00:00:00 +0000</p> <p>I used to write tests the way I wrote the first functions I ever wrote in Go — flat, repetitive, and with names so generic that when they failed, I had no idea which case broke. “TestParseDate failed” is not information. It’s a dare. Go figure out which of the twelve implicit cases in the body is responsible. I wasted hours doing exactly that before I committed to subtests.</p> <p><code>t.Run</code> is one of those language features that looks like a small convenience and turns out to be load-bearing for any serious test suite. Once you start using it, you wonder how you ever shipped anything without it.</p> </article> <article> <h1>Lesson 4: DNS — Resolution, caching, and why changes take time</h1> <p>Sat, 15 Jun 2024 00:00:00 +0000</p> <p>We pushed a production incident fix at 3am — rotated to a new IP address for a critical service, updated the DNS record, set the TTL to 60 seconds. Thirty minutes later, half our users were still hitting the broken server. The other half were fine. We had updated the DNS record correctly. The TTL had expired. Yet somehow, stale answers were persisting. That night taught me more about DNS than any documentation had.</p> </article> <article> <h1>Lesson 3: Trait Bounds — Constraining generic types</h1> <p>Fri, 14 Jun 2024 21:10:00 +0000</p> <p>I once wrote a generic function that looked perfectly reasonable — accepted any <code>T</code>, did some work, returned a result. It compiled. Then I tried to actually <em>use</em> it with a type that didn’t have <code>Clone</code>, 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.</p> </article> <article> <h1>Lesson 14: Pin and Unpin — Why Async Needs Them</h1> <p>Fri, 14 Jun 2024 20:05:00 +0000</p> <p><code>Pin</code> is the concept that makes experienced Rust developers pause. Not because it’s inherently complex — it’s actually a pretty small API — but because understanding <em>why</em> it exists requires connecting several ideas: self-referential structs, async/await desugaring, and move semantics.</p> <p>I struggled with Pin for months. Then I understood what async does under the hood, and Pin suddenly made perfect sense. So that’s how I’m going to explain it.</p> <h2 id="the-setup-what-async-really-does">The Setup: What Async Really Does</h2> <p>When you write an async function:</p> </article> <article> <h1>Lesson 1: HTTP Client Internals — Transport, connection reuse, and the pool you forgot to configure</h1> <p>Fri, 14 Jun 2024 00:00:00 +0000</p> <p>The first production Go service I wrote hammered our database proxy with thousands of new TCP connections every minute. The proxy started refusing connections. The on-call engineer thought it was the database. It wasn’t. It was me — specifically, my decision to create a new <code>http.Client</code> on every request and then never read the response body to completion. I spent three hours debugging what turned out to be two lines of misunderstood standard library behavior.</p> </article> <article> <h1>Lesson 5: Trees and BSTs — Why your database is a tree</h1> <p>Thu, 13 Jun 2024 00:00:00 +0000</p> <p>When you run <code>SELECT * FROM orders WHERE user_id = 42</code>, your database doesn’t scan every row. It walks a tree. Understanding why databases chose trees over hash maps — and which kind of tree, and why — is one of those “oh, everything makes sense now” moments that changes how you design systems.</p> <p>Let me start with binary search trees, get honest about their weaknesses, and set up the foundation for B-trees in the next lesson.</p> </article> <article> <h1>Lesson 2: Default Implementations and Selective Overrides — Don't repeat yourself</h1> <p>Wed, 12 Jun 2024 14:45:00 +0000</p> <p>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 <em>identical</em> method bodies. I was copying the same three lines into five <code>impl</code> blocks like a human xerox machine. There had to be a better way.</p> <p>There is. Default implementations.</p> <h2 id="the-basics">The Basics</h2> <p>A trait can provide a default body for any of its methods. Implementors can then choose to override it — or just accept the default:</p> </article> <article> <h1>Lesson 1: Designing HTTP APIs in Go — net/http is enough</h1> <p>Wed, 12 Jun 2024 00:00:00 +0000</p> <p>I spent the first few months of writing Go services reaching straight for a framework. Chi, Gorilla, Echo — I cycled through them trying to find the “right” one. Then a colleague reviewed my code and asked a simple question: “What does this framework give you that <code>net/http</code> doesn’t?” I couldn’t answer. That conversation changed how I think about HTTP in Go.</p> <h2 id="the-problem">The Problem</h2> <p>Most developers coming from Node.js or Python assume they need a framework to build a real HTTP API. Express, FastAPI, Django — these tools abstract away so much of the protocol that going back to the raw standard library feels like stepping down. But Go’s <code>net/http</code> package is not an afterthought. It was designed with production use in mind, and the gap between it and popular frameworks is much smaller than you’d expect.</p> </article> <article> <h1>Lesson 4: TCP/IP Stack — SYN Floods, TIME_WAIT, Connection Tuning</h1> <p>Tue, 11 Jun 2024 00:00:00 +0000</p> <p>A load test I ran against a Go HTTP server one afternoon produced a strange result: throughput leveled off at about 30,000 requests per second and couldn’t go higher, even though CPU was at 30%. Running <code>netstat -an | grep TIME_WAIT | wc -l</code> showed over 28,000 connections in <code>TIME_WAIT</code> state. The kernel was running out of local port numbers. Understanding TCP connection states — and how to tune Linux’s TCP stack — unblocked the test and taught me more about networking than any course had. This lesson covers the TCP mechanics that actually matter for backend engineers running high-throughput services.</p> </article> <article> <h1>Lesson 1: Trait Fundamentals — Defining shared behavior</h1> <p>Mon, 10 Jun 2024 09:22:00 +0000</p> <p>I spent my first month in Rust writing <code>impl</code> 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.”</p> </article> <article> <h1>Lesson 13: Weak References — Breaking Cycles</h1> <p>Mon, 10 Jun 2024 09:15:00 +0000</p> <p>Reference counting has a fatal flaw: cycles. If A owns B and B owns A, neither reference count hits zero. The memory is leaked — not freed when it should be, not freed ever. In a garbage-collected language, the GC would detect this cycle and clean it up. Rust’s <code>Rc</code>/<code>Arc</code> can’t do that.</p> <p><code>Weak</code> references are the solution. And honestly, if you understand why they exist, you understand half of what makes garbage collectors complex.</p> </article> <article> <h1>Lesson 1: Interface Representation — Two words that carry your abstractions</h1> <p>Mon, 10 Jun 2024 00:00:00 +0000</p> <p>I remember the first time I hit a bug where <code>err != nil</code> returned <code>true</code> even though the function clearly returned <code>nil</code>. I spent forty minutes staring at perfectly reasonable-looking code before I realized I had no idea what an interface actually <em>is</em> at the memory level. Once I understood the two-word representation, that class of bug never confused me again.</p> <h2 id="the-problem">The Problem</h2> <p>Go interfaces are the backbone of polymorphism in the language. You use them constantly — <code>io.Reader</code>, <code>error</code>, <code>fmt.Stringer</code>. But most developers treat them as magic. You assign a concrete value, you call methods, and somehow Go figures out which implementation to dispatch to at runtime.</p> </article> <article> <h1>Lesson 4: MVCC — How Postgres Handles Concurrent Reads and Writes</h1> <p>Sun, 09 Jun 2024 00:00:00 +0000</p> <p>One thing that puzzled me early on was how Postgres could let me read from a table while someone else was writing to it — without locking me out and without me seeing half-written data. Most systems I had worked with used explicit read locks, which meant readers and writers had to take turns. Postgres doesn’t do that. Reads never block writes, and writes never block reads. The mechanism that makes this possible is called Multiversion Concurrency Control, or MVCC, and it works by keeping multiple versions of every row simultaneously.</p> </article> <article> <h1>Lesson 1: When NOT to Use Interfaces — Abstractions cost clarity</h1> <p>Sat, 08 Jun 2024 00:00:00 +0000</p> <p>The first time I saw Go interfaces click in a codebase, I made the same mistake every developer makes: I started reaching for them everywhere. If I had a struct, I made an interface for it. If I had two types that shared even one method name, I defined an interface over both. It felt disciplined. It felt like proper software engineering. It was making my code worse.</p> <p>The uncomfortable truth about Go interfaces is that they are most powerful when you use them least. Unlike Java, where every class implementing an interface is an explicit declaration, Go interfaces are satisfied implicitly. That means there is almost zero syntax cost to adding one. And that near-zero cost hides the real cost: cognitive overhead, indirection, and the loss of explicit signal about what a piece of code actually does.</p> </article> <article> <h1>Lesson 3: Incident Response — Postmortems and blameless culture</h1> <p>Sat, 08 Jun 2024 00:00:00 +0000</p> <p>The first major incident I was on-call for, I spent 90 minutes trying to fix the problem and 30 minutes frantically communicating to stakeholders in a panic. The second one, I followed a runbook and spent the 90 minutes coordinating, communicating clearly, and delegating diagnosis — while the problem was resolved in 40 minutes. The difference wasn’t technical skill. It was process. Incident response is a skill you can learn and practice, and it makes a measurable difference in how quickly you restore service and how well the team learns from failures.</p> </article> <article> <h1>Lesson 12: Rc and Arc — Shared Ownership</h1> <p>Fri, 07 Jun 2024 17:50:00 +0000</p> <p>Rust’s ownership model says every value has one owner. But what happens when multiple parts of your program genuinely need to own the same data? Trees with shared nodes. Graphs with cycles. Observer patterns. Caches shared between subsystems.</p> <p>Single ownership doesn’t fit everything. <code>Rc</code> and <code>Arc</code> are Rust’s answer — reference-counted smart pointers that enable shared ownership with deterministic cleanup.</p> <h2 id="the-problem-multiple-owners">The Problem: Multiple Owners</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#75715e">// This doesn't work — who owns the shared config? </span></span></span><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">ServiceA</span> { </span></span><span style="display:flex;"><span> config: <span style="color:#a6e22e">AppConfig</span>, <span style="color:#75715e">// owns it </span></span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">ServiceB</span> { </span></span><span style="display:flex;"><span> config: <span style="color:#a6e22e">AppConfig</span>, <span style="color:#75715e">// also owns a copy? expensive clone </span></span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>You could pass references, but then you’re dealing with lifetimes everywhere. And if the config needs to outlive any individual service, you need <code>'static</code> or owned data.</p> </article> <article> <h1>Lesson 1: What Generics Solve in Go — Remove duplication without hiding intent</h1> <p>Fri, 07 Jun 2024 00:00:00 +0000</p> <p>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 <code>MinInt</code>, <code>MinFloat64</code>, <code>MinInt64</code>, and a comment that said “do not touch, generated.” That’s when I started caring.</p> <p>Generics in Go aren’t a revolution. They’re a targeted fix for a specific, real pain point: you had to either use <code>interface{}</code> and lose type safety, or repeat yourself across every concrete type you cared about. Neither option aged well.</p> </article> <article> <h1>Lesson 1: GraphQL vs REST — When GraphQL wins and when it doesn't</h1> <p>Thu, 06 Jun 2024 00:00:00 +0000</p> <p>I spent about six months being wrong about GraphQL. My first exposure to it was a rewrite pitch from a frontend engineer who was tired of making five REST calls to assemble one screen. “GraphQL solves this,” they said, and the demo looked compelling. A single query, exactly the fields you need, one round trip. I was sold before thinking carefully about what we were buying.</p> <p>The rewrite happened. It took eight months instead of four. Some of the problems we were trying to solve got better. Others got worse. Looking back, the mistake wasn’t choosing GraphQL — it was not being rigorous about where GraphQL actually wins and where it doesn’t before committing.</p> </article> <article> <h1>Lesson 1: Input Validation — Trust nothing from the wire</h1> <p>Wed, 05 Jun 2024 00:00:00 +0000</p> <p>The first production security incident I dealt with involved a simple integer field in a JSON body. The client sent a negative number where we expected a positive quantity. We hadn’t validated it. The result was a negative charge on a purchase — we were effectively paying customers money. That taught me more about input validation than any security course.</p> <p>Every byte that arrives over the wire is adversarial by default. Not because every user is malicious, but because your assumptions about the data are not enforced by anything except your own code. HTTP gives you a byte stream. JSON decoding gives you Go values. Neither of those steps checks whether the values make sense for your business logic. That job is yours.</p> </article> <article> <h1>Lesson 4: Database Scaling — Read Replicas, Sharding, and When Each Helps</h1> <p>Wed, 05 Jun 2024 00:00:00 +0000</p> <p>Your startup ships, gains traction, and one day your database becomes the bottleneck. Queries slow down. CPU spikes. The single machine hosting your Postgres instance can’t keep up. This is one of the most predictable problems in engineering, yet I’ve seen teams reach it completely unprepared because they’d never thought carefully about how databases scale. The right solution depends entirely on whether you’re read-heavy or write-heavy, whether your data is relational or not, and whether your workload is even or spiky.</p> </article> <article> <h1>Lesson 11: Interior Mutability — Cell, RefCell, and the Rules</h1> <p>Tue, 04 Jun 2024 11:30:00 +0000</p> <p>Rust’s borrowing rules say you can’t mutate through a shared reference. Period. Except — sometimes you need to. Caching, reference counting, lazy initialization, mock objects in tests. Legitimate use cases where the “no mutation through <code>&T</code>” rule is too restrictive.</p> <p>Interior mutability is the escape hatch. It moves the borrow check from compile time to runtime. And yes, it can panic if you get it wrong. That’s the tradeoff.</p> <h2 id="the-problem-mutation-through-self">The Problem: Mutation Through &self</h2> <p>You’re building a struct with a method that logically doesn’t modify the struct’s public state but needs to update some internal bookkeeping:</p> </article> <article> <h1>Lesson 1: Range Over Integers and Iterators — for i := range 10 and the iterator protocol</h1> <p>Tue, 04 Jun 2024 00:00:00 +0000</p> <p>I have written <code>for i := 0; i < n; i++</code> so many times that my fingers type it on autopilot. The three-clause for loop is fine — it works, everyone understands it, and Go has always had it. But when Go 1.22 shipped <code>for i := range 10</code>, I stopped and stared at it for a moment. Not because it was complicated. Because it was so obviously the right thing that I wondered why it had taken this long.</p> </article> <article> <h1>Lesson 3: Event-Driven Architecture — Events vs commands</h1> <p>Tue, 04 Jun 2024 00:00:00 +0000</p> <p>I used to use “event” and “command” interchangeably. A message is a message, right? Then I started debugging an event-driven system where the payment service was publishing <code>ProcessPayment</code> events, the order service was publishing <code>CreateShipment</code> events, and two teams were arguing about who owned the workflow. The problem was naming: they were publishing commands disguised as events. The distinction isn’t pedantic — it determines who owns the workflow and how the system evolves.</p> </article> <article> <h1>Lesson 1: Package Boundaries — One package, one responsibility, zero excuses</h1> <p>Mon, 03 Jun 2024 00:00:00 +0000</p> <p>I have refactored a lot of Go codebases — my own included. And the single most common structural mistake I see is the <code>utils</code> package. Or <code>helpers</code>. Or <code>common</code>. Or sometimes the worst offender of all: a package named after the entire application domain with fifty unrelated files sitting inside it. When I first started writing Go seriously, I made all of these mistakes. This lesson is about why package boundaries matter and how to get them right.</p> </article> <article> <h1>Lesson 10: Self-Referential Structs — The Problem and Solutions</h1> <p>Sun, 02 Jun 2024 15:40:00 +0000</p> <p>Every Rust developer eventually tries to build this: a struct that owns some data AND holds a reference into that data. It seems perfectly reasonable. It’s also the single thing Rust refuses to let you do safely — and for very good reasons.</p> <p>I wasted two days on this in my second month of Rust. Let me save you those two days.</p> <h2 id="the-desire">The Desire</h2> <p>You want a struct like this:</p> </article> <article> <h1>Lesson 1: ML Pipelines — From raw data to deployed model</h1> <p>Sun, 02 Jun 2024 00:00:00 +0000</p> <p>The first time I built a “production ML pipeline,” it was a cron job that ran a Python script, trained a model, and saved the artifact to disk. It worked, until it didn’t. The model silently degraded over three weeks because the training data schema changed and nobody noticed. There were no tests, no validation, no monitoring. That experience, embarrassing as it was, taught me more about ML system design than any paper on model architecture.</p> </article> <article> <h1>Lesson 4: Two Pointers and Sliding Window — Stream processing in disguise</h1> <p>Sat, 01 Jun 2024 00:00:00 +0000</p> <p>The first time I recognized the sliding window pattern outside a textbook, I was reading the source code for a rate limiter. There was no comment saying “sliding window algorithm here.” There was just a loop, two indices into a circular buffer, and some simple arithmetic that maintained a count of events in the last N seconds. Once I saw it, I started seeing it everywhere — in network flow control, in moving average calculations, in deduplication logic.</p> </article> <article> <h1>Lesson 9: Higher-Ranked Trait Bounds — for<'a> Explained</h1> <p>Fri, 31 May 2024 21:15:00 +0000</p> <p>If regular lifetime annotations are Rust’s intermediate boss, <code>for<'a></code> is the final boss. Higher-Ranked Trait Bounds (HRTBs) look terrifying in signatures, but they solve a very specific and real problem.</p> <p>I avoided understanding HRTBs for over a year. Then I tried to write a function that takes a closure accepting references with <em>any</em> lifetime, and suddenly I had no choice. Let me save you that year.</p> <h2 id="the-problem">The Problem</h2> <p>Say you want a function that accepts a closure. The closure takes a <code>&str</code> and returns something:</p> </article> <article> <h1>Lesson 6: Linked Lists — Pointer Manipulation Is the Real Test</h1> <p>Fri, 31 May 2024 00:00:00 +0000</p> <p>Linked lists are where candidates reveal whether they actually understand pointers. You can read a hundred tutorials on reversing a linked list, but the first time you try to code it under pressure, you will likely lose a node, corrupt the list, or write an infinite loop. I know because it happened to me in a mock interview. The problem itself is not hard. The pointer mechanics are.</p> <p>This lesson is about building the mental model that makes pointer operations feel mechanical rather than scary. Meta asks linked list questions constantly — their systems rely heavily on custom allocators and cache implementations, and linked lists are the natural test vehicle. Amazon uses the LRU cache variant to test both data structure design and implementation discipline.</p> </article> <article> <h1>Lesson 3: TLS Handshake — What happens in those 2 round trips</h1> <p>Thu, 30 May 2024 00:00:00 +0000</p> <p>A colleague once asked me why adding TLS to a service increased our P99 latency by 50ms. She had measured it carefully, switching between HTTP and HTTPS in a load test. My first instinct was to say “encryption overhead” but that’s wrong — modern CPUs with AES-NI can encrypt gigabytes per second. The actual cost is the handshake. Once I explained what was actually happening in those first few round trips, the answer to “how do we fix it” became obvious: stop creating new connections.</p> </article> <article> <h1>Lesson 8: 'static — Not What You Think</h1> <p>Wed, 29 May 2024 13:25:00 +0000</p> <p><code>'static</code> is the most misunderstood lifetime in Rust. Most people think it means “lives forever” or “global variable.” It kind of does — but also doesn’t. And the way it interacts with trait bounds will surprise you.</p> <p>I’ve seen experienced Rust developers get this wrong. So don’t feel bad if it’s been confusing.</p> <h2 id="what-static-actually-means">What ‘static Actually Means</h2> <p><code>'static</code> means: “this reference is valid for the entire duration of the program.”</p> </article> <article> <h1>Lesson 4: Stacks and Queues — The structures hiding in every system</h1> <p>Tue, 28 May 2024 00:00:00 +0000</p> <p>Every time you make a function call, your program uses a stack. Every HTTP request in a web server sits in a queue. Every undo operation in your IDE is a stack. These structures are so fundamental they’re baked into the hardware itself — the CPU has dedicated stack instructions.</p> <p>Yet I consistently see engineers reach for generic slices or channels when a properly implemented stack or queue would be both clearer and faster. Let me show you what these structures actually are, why they’re the shape they are, and where they show up in the systems you work on every day.</p> </article> <article> <h1>Lesson 7: Lifetimes in Structs — References That Live in Types</h1> <p>Mon, 27 May 2024 10:42:00 +0000</p> <p>Putting a reference inside a struct is where lifetimes go from “mildly confusing” to “wait, what?” for most people. I remember spending an entire afternoon trying to make a struct hold a <code>&str</code> and wondering why the compiler kept yelling at me.</p> <p>The fundamental tension: structs outlive function calls. References might not. The compiler needs you to prove the reference won’t dangle.</p> <h2 id="the-problem">The Problem</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#75715e">// This won't compile </span></span></span><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Excerpt</span> { </span></span><span style="display:flex;"><span> content: <span style="color:#66d9ef">&</span><span style="color:#66d9ef">str</span>, </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><pre tabindex="0"><code>error[E0106]: missing lifetime specifier --> src/main.rs:2:14 | 2 | content: &str, | ^ expected named lifetime parameter </code></pre><p>Why? Because the compiler needs to know: how long does the thing <code>content</code> points to live? Without that information, it can’t guarantee the reference is valid for the struct’s entire lifetime.</p> </article> <article> <h1>Lesson 3: File Descriptors — Why Too Many Open Files Kills Your Server</h1> <p>Mon, 27 May 2024 00:00:00 +0000</p> <p>I got a 3 AM page for a service that was returning connection errors to every client. The application logs said <code>dial tcp: lookup ...: too many open files</code>. We hadn’t changed anything. Load was normal. But over 48 hours, something had been slowly accumulating open file descriptors and not closing them, and we hit the per-process limit. Restarting the service fixed the immediate problem; understanding why it happened required me to actually learn what file descriptors are and how the kernel manages them.</p> </article> <article> <h1>Lesson 6: Lifetime Elision Rules — Why You Usually Don't Write 'a</h1> <p>Sat, 25 May 2024 19:08:00 +0000</p> <p>If lifetimes are so important, why don’t you see <code>'a</code> plastered all over most Rust code? Because the compiler is smart enough to figure it out 90% of the time.</p> <p>Early Rust required explicit lifetime annotations on every function that dealt with references. The community quickly realized that the same patterns showed up over and over. So the Rust team codified those patterns into “elision rules” — three rules that let the compiler infer lifetimes automatically.</p> </article> <article> <h1>Lesson 2: Design Uber — Real-time matching, geospatial indexing, surge pricing</h1> <p>Sat, 25 May 2024 00:00:00 +0000</p> <p>Uber is one of the most instructive system design problems because it forces you to think about real-time data pipelines, spatial indexing, and latency-sensitive matching algorithms all at once. I spent a significant amount of time studying this problem specifically because the geospatial angle is something most candidates gloss over. They say “use a database with location queries” and move on. But at Uber’s scale — 5 million trips per day, hundreds of thousands of concurrent drivers and riders — the geospatial indexing strategy is the entire problem.</p> </article> <article> <h1>Lesson 1: Pod Design Patterns — Sidecar, ambassador, adapter</h1> <p>Fri, 24 May 2024 00:00:00 +0000</p> <p>The first time I deployed a service to Kubernetes, I put everything in a single container. Logging, metrics, TLS termination, the actual application — all in one Docker image. It worked, but the image was massive, updating any single concern meant rebuilding and redeploying the whole thing, and the application team had to understand infrastructure concerns they shouldn’t need to care about. The sidecar pattern was the thing that changed how I thought about container composition.</p> </article> <article> <h1>Lesson 5: Lifetime Annotations — Teaching the Compiler Relationships</h1> <p>Thu, 23 May 2024 08:55:00 +0000</p> <p>Lifetime annotations are where most people’s Rust learning hits a wall. The syntax looks alien. The error messages talk about “named lifetimes.” Your code compiles fine until you add a second reference parameter, and then suddenly the compiler wants you to annotate things with <code>'a</code>.</p> <p>Here’s the thing most tutorials get wrong: lifetime annotations don’t change how long anything lives. They describe relationships that already exist.</p> <h2 id="why-lifetimes-exist">Why Lifetimes Exist</h2> <p>Consider this function:</p> </article> <article> <h1>Lesson 3: Write-Ahead Log — How Databases Survive Crashes</h1> <p>Thu, 23 May 2024 00:00:00 +0000</p> <p>Databases promise durability. When <code>INSERT</code> returns successfully, your data is safe — even if the server loses power a millisecond later. For a long time I accepted this as magic. Then I started reading about what actually happens when Postgres writes data, and the mechanism behind that promise is both elegant and counterintuitive: to make writes safe, you write them twice. The first write goes to a sequential log. The second write goes to the actual data file. And the log is what saves you when things go wrong.</p> </article> <article> <h1>Lesson 25: When to Reach for unsafe — And when not to</h1> <p>Wed, 22 May 2024 17:08:00 +0000</p> <p>This is the lesson I almost didn’t write. Not because <code>unsafe</code> is hard to explain, but because most Rust developers will never need it — and I don’t want to encourage reaching for it prematurely. I’ve seen codebases riddled with <code>unsafe</code> blocks because the developer didn’t know the safe alternative existed. That’s the worst outcome.</p> <p>But <code>unsafe</code> exists for a reason. Understanding when it’s appropriate — and more importantly, when it isn’t — is part of being a competent Rust developer.</p> </article> <article> <h1>Lesson 2: Code Review That Works — What to look for</h1> <p>Wed, 22 May 2024 00:00:00 +0000</p> <p>I’ve been on the wrong end of bad code reviews in both directions. Reviews that were nitpick sessions about variable naming while missing a race condition. Reviews that rubber-stamped everything because the reviewer was busy. And I’ve given both kinds myself. It took a few years, a few incidents, and a few honest retrospectives to develop a framework for reviews that actually improve code quality without burning out reviewers or demoralizing authors.</p> </article> <article> <h1>Lesson 4: The Borrow Checker — What It's Really Doing</h1> <p>Tue, 21 May 2024 16:33:00 +0000</p> <p>I used to think the borrow checker was my enemy. It rejected valid programs! It made simple things hard! It was too conservative!</p> <p>Then I started maintaining a large C++ codebase and found three use-after-free bugs in one week. The borrow checker stopped looking like an enemy real fast.</p> <h2 id="borrowing-using-without-owning">Borrowing: Using Without Owning</h2> <p>Ownership transfer is clean but inflexible. You can’t always afford to give your data away — sometimes you just want to let another function <em>look at it</em> for a moment. That’s borrowing.</p> </article> <article> <h1>Lesson 24: Writing Great Rust Documentation — rustdoc that actually helps</h1> <p>Mon, 20 May 2024 14:30:00 +0000</p> <p>The Rust ecosystem has some of the best documentation I’ve seen in any language. And it’s not an accident — the tooling actively <em>encourages</em> good documentation. Doc comments are first-class citizens. Examples in docs are compiled and tested. The standard library sets an impossibly high bar that crate authors actually try to meet.</p> <p>If you’re publishing a crate and the docs are an afterthought, you’re doing it wrong. Documentation is the API.</p> </article> <article> <h1>Lesson 3: Caching — The Hardest Easy Problem in CS</h1> <p>Mon, 20 May 2024 00:00:00 +0000</p> <p>Phil Karlton supposedly said: “There are only two hard things in Computer Science: cache invalidation and naming things.” He was joking, but also completely serious. Caching is the answer to nearly every “make it faster” problem in system design. It’s also the source of some of the most insidious bugs in production: stale data served with confidence, cache stampedes that take down your database, memory explosions from an unbounded cache. The concept is simple. Getting it right is not.</p> </article> <article> <h1>Lesson 3: Copy vs Clone — When Data Gets Duplicated</h1> <p>Sun, 19 May 2024 11:10:00 +0000</p> <p>A coworker once asked me: “If Rust moves everything, how do I ever use a value twice?” Fair question. The answer is two traits that look similar but behave very differently — <code>Copy</code> and <code>Clone</code>.</p> <p>Getting these confused will either tank your performance or confuse the hell out of you. Probably both.</p> <h2 id="copy-implicit-cheap-and-bitwise">Copy: Implicit, Cheap, and Bitwise</h2> <p><code>Copy</code> is a marker trait. It tells the compiler: “this type is so cheap to duplicate that you should do it automatically on assignment instead of moving.”</p> </article> <article> <h1>Lesson 2: Clean Architecture — Not the textbook version</h1> <p>Sun, 19 May 2024 00:00:00 +0000</p> <p>I’ve read the Clean Architecture book. I’ve also seen teams implement it so literally that they had six layers of indirection for a CRUD endpoint: a controller called a use case, which called a domain service, which called a port, which went through an adapter, which called a repository, which hit the database. Each hop had its own error mapping. Changing a database column required touching eight files. That’s not clean. That’s engineering theater.</p> </article> <article> <h1>Lesson 23: Clippy Is Your Mentor — Listen to it</h1> <p>Sat, 18 May 2024 10:55:00 +0000</p> <p>I’ll say something controversial: Clippy taught me more about idiomatic Rust than any book. Not because it explains concepts — it doesn’t. But because it catches you every time you write non-idiomatic code and shows you the better way. It’s like having a senior Rust developer looking over your shoulder, constantly saying “there’s a cleaner way to do that.”</p> <p>Run <code>cargo clippy</code> on every project. Every commit. No exceptions.</p> <hr> <h2 id="what-clippy-is">What Clippy Is</h2> <p>Clippy is Rust’s official linter — over 700 lint rules that catch everything from style issues to actual bugs. It ships with rustup, so you already have it.</p> </article> <article> <h1>Lesson 3: Binary Search — The most useful algorithm you'll use weekly</h1> <p>Sat, 18 May 2024 00:00:00 +0000</p> <p>Binary search has a reputation as a simple algorithm — and it is, conceptually. Divide the search space in half, check the middle, repeat. Every programmer knows this. Yet I have seen engineers reach for a linear scan when binary search would have solved the problem in a fraction of the time, and I have also seen subtly buggy binary search implementations that work 99.9% of the time and silently fail on edge cases.</p> </article> <article> <h1>Lesson 2: Move Semantics — Why Assignment Transfers Ownership</h1> <p>Fri, 17 May 2024 14:45:00 +0000</p> <p>The first time Rust told me I couldn’t use a variable after assigning it to another one, I stared at my screen for a solid minute. In what universe does <code>let b = a</code> make <code>a</code> invalid?</p> <p>This universe. Rust’s universe. And honestly — it’s the only sane default.</p> <h2 id="what-a-move-actually-is">What a Move Actually Is</h2> <p>In most languages, <code>let b = a</code> copies the data or copies a reference. In Rust, for heap-allocated types, it <em>moves</em> the ownership. The bits get copied (the stack portion — pointer, length, capacity), but the old variable is invalidated.</p> </article> <article> <h1>Lesson 22: Feature Flags and Conditional Compilation — cfg and features</h1> <p>Thu, 16 May 2024 12:45:00 +0000</p> <p>I once worked on a crate that pulled in 200+ transitive dependencies because it unconditionally depended on <code>tokio</code>, <code>serde</code>, <code>reqwest</code>, and <code>tracing</code>. Most users only needed one of those. The compile time was brutal, and the binary was enormous.</p> <p>Feature flags solve this. They let users opt into functionality they need and skip everything else. It’s the “pay for what you use” principle applied to compilation.</p> <hr> <h2 id="cfg--conditional-compilation">cfg — Conditional Compilation</h2> <p>The <code>#[cfg(...)]</code> attribute conditionally includes code based on compile-time configuration:</p> </article> <article> <h1>Lesson 1: Leader Election — Someone has to be in charge</h1> <p>Thu, 16 May 2024 00:00:00 +0000</p> <p>I spent three days debugging a production incident where two nodes in our cluster both believed they were the primary. Each was accepting writes. Each was replicating to followers. Each was convinced the other was dead. By the time we noticed, we had diverged state that took two more days to reconcile. That incident made me obsessive about leader election — not as an academic concept, but as a concrete engineering problem with real failure modes.</p> </article> <article> <h1>Lesson 1: The Mental Model — Stack, Heap, and Ownership</h1> <p>Wed, 15 May 2024 09:22:00 +0000</p> <p>I spent my first three months in Rust confused about ownership. Not because the concept is hard — it’s genuinely simple — but because every tutorial I read explained it through the lens of “rules to memorize.” Three rules. Memorize them. Move on.</p> <p>That’s backwards. You don’t learn ownership by memorizing rules. You learn it by understanding where your data actually lives.</p> <h2 id="where-data-lives-changes-everything">Where Data Lives Changes Everything</h2> <p>Every value in your program sits in one of two places: the stack or the heap. If you’ve done any C or C++, this is familiar territory. If you haven’t — don’t worry, this isn’t as scary as systems programmers make it sound.</p> </article> <article> <h1>Lesson 3: Hash Maps — O(1) with asterisks</h1> <p>Wed, 15 May 2024 00:00:00 +0000</p> <p>Hash maps are the workhorse of production software. Nearly every caching layer, session store, deduplication system, and configuration lookup you’ve ever written relies on one. They’re fast, they’re flexible, and they’re genuinely O(1) — with some asterisks that matter enormously in production.</p> <p>I want to walk through how they actually work, because the “O(1) lookup” claim hides a lot of complexity that shows up in the worst possible moments: under load, with adversarial input, or when your hash function is subtly wrong.</p> </article> <article> <h1>Lesson 21: The Turbofish ::<> — Explicit type parameters</h1> <p>Tue, 14 May 2024 08:22:00 +0000</p> <p>The first time I saw <code>::<></code> in Rust code, I thought someone was having a stroke at the keyboard. <code>collect::<Vec<_>>()</code>? What is that colon-colon-angle-bracket monstrosity?</p> <p>It’s called the turbofish. Named by the community because <code>::<></code> looks like a fish (<code>::<></code> — see the eyes and the mouth?). It’s goofy. It’s lovable. And once you understand it, you’ll use it constantly.</p> <hr> <h2 id="what-the-turbofish-does">What the Turbofish Does</h2> <p>The turbofish provides explicit type parameters to generic functions or methods when the compiler can’t infer them.</p> </article> <article> <h1>Lesson 2: HTTP/2 and HTTP/3 — Multiplexing and QUIC</h1> <p>Tue, 14 May 2024 00:00:00 +0000</p> <p>The first time I looked at a waterfall chart in Chrome DevTools and saw a hundred requests stacking up like rush-hour traffic, I knew HTTP/1.1 was the problem. We had a dashboard loading twelve API calls and a handful of assets, and they were all waiting in line. Not because the server was slow — it was idle — but because the browser had a six-connection-per-host limit and every request had to wait its turn. That was my introduction to why HTTP/2 exists, and it changed how I think about protocol design.</p> </article> <article> <h1>Lesson 20: API Design Guidelines — The Rust way</h1> <p>Sun, 12 May 2024 16:40:00 +0000</p> <p>I’ve written APIs in a dozen languages, and Rust is the only one where the community has near-universal agreement on how APIs should look. There’s an unofficial (but incredibly thorough) Rust API Guidelines document, and most popular crates follow it closely. When you learn these conventions, every new crate feels familiar.</p> <p>Here’s what I’ve distilled from reading hundreds of crate APIs and writing a few of my own.</p> <hr> <h2 id="naming-conventions">Naming Conventions</h2> <p>Rust has strong naming conventions, and deviating from them makes your crate feel alien.</p> </article> <article> <h1>Lesson 2: Virtual Memory — 1GB RSS but Only 50MB is Real</h1> <p>Sun, 12 May 2024 00:00:00 +0000</p> <p>Early in my career I deployed a Go service and checked <code>top</code>. The <code>VIRT</code> column showed 1.2 GB. I nearly had a heart attack — our server had 4 GB of RAM and I thought the service was consuming nearly a third of it. A senior engineer laughed and told me to look at <code>RES</code> instead: 52 MB. I had no idea what the difference was. Understanding virtual memory is fundamental to reading memory metrics correctly, debugging out-of-memory kills, and understanding how processes interact with the kernel.</p> </article> <article> <h1>Lesson 25: What's Next — Your roadmap from beginner to production Go</h1> <p>Sat, 11 May 2024 00:00:00 +0000</p> <p>You made it. Twenty-five lessons ago you didn’t know what <code>package main</code> meant. Now you understand variables, types, functions, error handling, interfaces, goroutines, testing, JSON, file I/O, the type system, and the entire toolchain. That is not beginner knowledge anymore.</p> <p>But there’s a gap between knowing the language and writing Go the way experienced Go developers write it. This lesson is about that gap — what it is, how to close it, and what to build while you do.</p> </article> <article> <h1>Lesson 19: PhantomData — Tagging types without runtime cost</h1> <p>Fri, 10 May 2024 09:15:00 +0000</p> <p>When I first saw <code>PhantomData</code> in a codebase, I thought it was some kind of hack. A zero-sized field that exists only to satisfy the compiler? It felt like a workaround for a language limitation. But the more I used it, the more I realized it’s actually a precision tool — it lets you encode information in the type system without any runtime cost.</p> <p>We already used it in the typestate lesson. Now let’s understand it properly.</p> </article> <article> <h1>Lesson 1: The STAR Method — "Tell me about a time you..." and how to actually answer</h1> <p>Fri, 10 May 2024 00:00:00 +0000</p> <p>I used to dread behavioral interviews. I was confident in system design rounds, reasonably calm under algorithm pressure, but the moment someone said “tell me about a time you disagreed with a technical decision,” I felt my brain empty out completely. I would ramble for two minutes, lose the thread halfway through, and trail off into something like “…so yeah, it worked out eventually.” Not exactly compelling.</p> <p>The STAR method fixed that — not because it’s magic, but because it gives a structure that stops you from wandering. Situation, Task, Action, Result. Four buckets. Every behavioral answer you’ll ever give fits into them.</p> </article> <article> <h1>Lesson 5: Binary Search — When the Search Space Is Sorted or Monotonic</h1> <p>Thu, 09 May 2024 00:00:00 +0000</p> <p>Binary search has a reputation as the thing you learned in your first CS course and never thought about deeply again. Then you encounter a rotated array or a capacity-minimization problem in an interview, and suddenly it is not obvious at all. I’ve seen engineers who could recite the textbook implementation fail completely on problems that are, at their core, binary search — because the search space isn’t an array of values, it’s something more abstract.</p> </article> <article> <h1>Lesson 18: Drop and RAII — Deterministic cleanup</h1> <p>Wed, 08 May 2024 11:30:00 +0000</p> <p>In Go, you write <code>defer f.Close()</code> and hope you didn’t forget one. In Python, you use <code>with</code> blocks and hope the context manager is implemented correctly. In Java, you use try-with-resources and hope <code>AutoCloseable.close()</code> doesn’t throw. In C, you write <code>free()</code> and pray.</p> <p>In Rust, cleanup happens automatically when a value goes out of scope. Always. No exceptions. No forgetting. That’s RAII — Resource Acquisition Is Initialization — and the <code>Drop</code> trait is how Rust implements it.</p> </article> <article> <h1>Lesson 2: B-Tree Indexes — O(n) to O(log n) in one CREATE INDEX</h1> <p>Wed, 08 May 2024 00:00:00 +0000</p> <p>I once joined a team that had a <code>users</code> table with 8 million rows. The <code>GET /users/{email}</code> endpoint was consistently timing out under load. When I ran <code>EXPLAIN ANALYZE</code> on the query, I saw it: <code>Seq Scan on users (cost=0.00..180000.00 rows=1 width=120) (actual rows=1 loops=1)</code>. It was reading every single row — all 8 million of them — to find one user by email. Adding a single index fixed it in under five minutes. That experience made me want to actually understand what an index is, not just that it makes things faster.</p> </article> <article> <h1>Lesson 1: Git Beyond Basics — Rebase, bisect, worktrees</h1> <p>Tue, 07 May 2024 00:00:00 +0000</p> <p>Most engineers use maybe 15% of Git. <code>add</code>, <code>commit</code>, <code>push</code>, <code>pull</code>, <code>branch</code>, <code>merge</code>, and <code>status</code> covers daily work. That’s fine until you need to find which commit introduced a regression across 300 commits, or you need to untangle a messy history before merging, or you want to work on three features simultaneously without context-switching overhead. The commands I’m covering here don’t come up every day. When they do, they save hours.</p> </article> <article> <h1>Lesson 24: The Go Toolchain — build, test, vet, fmt — your daily tools</h1> <p>Tue, 07 May 2024 00:00:00 +0000</p> <p>One of the things that drew me to Go was that the toolchain ships with the language. You don’t need to choose a build tool, a formatter, or a test framework — they’re all there from day one, and they’re all invoked the same way: <code>go <command></code>. This lesson is a tour of the tools you’ll use every single day.</p> <hr> <h2 id="the-basics">The Basics</h2> <h3 id="go-run-and-go-build">go run and go build</h3> <p>You’ve used <code>go run</code> throughout this course. It compiles your code and immediately executes it — perfect for development. Under the hood it creates a temporary binary and runs it, then throws the binary away.</p> </article> <article> <h1>Lesson 17: Zero-Cost Abstractions — What it actually means</h1> <p>Mon, 06 May 2024 14:52:00 +0000</p> <p>“Zero-cost abstractions” is Rust’s most-repeated promise and its most-misunderstood concept. People hear “zero cost” and think “free.” It doesn’t mean free. It means: <strong>you don’t pay for what you don’t use, and what you do use, you couldn’t hand-code any better.</strong></p> <p>That’s a Bjarne Stroustrup quote, originally about C++. But Rust actually delivers on it in ways C++ often doesn’t.</p> <hr> <h2 id="what-zero-cost-actually-means">What Zero-Cost Actually Means</h2> <p>Consider iterators. In Python, iterator chains create intermediate objects. In Java, streams can have overhead from boxing and virtual dispatch. In Rust:</p> </article> <article> <h1>Lesson 1: Lexing — Turning text into tokens</h1> <p>Mon, 06 May 2024 00:00:00 +0000</p> <p>I wrote my first lexer as a side project after reading the first chapter of “Writing an Interpreter in Go.” I expected it to be hard. It was not. A lexer is conceptually one of the simpler pieces of a compiler: read characters, group them into meaningful chunks, throw away whitespace. What surprised me was how much clarity it brought to everything downstream. Once I had tokens instead of characters, every subsequent step became easier to reason about. The text became structured. And the structure was entirely my design.</p> </article> <article> <h1>Lesson 16: Enums Over Booleans — Make illegal states unrepresentable</h1> <p>Sun, 05 May 2024 08:17:00 +0000</p> <p>I once spent an entire afternoon debugging a function with this signature: <code>process(data, true, false, true)</code>. Three booleans. What did they mean? I had to read the function definition every single time I encountered a call site. Is <code>true</code> for “verbose”? For “dry-run”? For “force”?</p> <p>Booleans are the most overused type in programming. They encode exactly one bit of information — yes or no — and they tell you nothing about <em>what question they’re answering</em>. Enums fix this.</p> </article> <article> <h1>Lesson 2: Load Balancing — L4 vs L7 and Why It Matters</h1> <p>Sun, 05 May 2024 00:00:00 +0000</p> <p>The first time I drew a system design diagram in an interview, I drew a box labeled “load balancer” and drew arrows from clients to it, and from it to servers. My interviewer asked, “What kind of load balancer?” I didn’t have an answer. I knew load balancers existed. I didn’t know they made fundamentally different decisions at different network layers — and that the choice between them shapes what your system can and cannot do.</p> </article> <article> <h1>Lesson 15: Exhaustive Matching — Let the compiler help</h1> <p>Fri, 03 May 2024 22:08:00 +0000</p> <p>A teammate once added a new payment method to our system — <code>CryptoCurrency</code> — and forgot to update the fee calculation logic. In production. For three weeks. Nobody noticed because the switch statement in Java had a <code>default</code> case that silently applied a 0% fee. Free crypto transfers for everyone.</p> <p>In Rust, the compiler would have caught this the moment the new variant was added. That’s exhaustive matching — and it’s one of Rust’s most underappreciated features.</p> </article> <article> <h1>Lesson 1: Monolith First — Starting with microservices is usually wrong</h1> <p>Fri, 03 May 2024 00:00:00 +0000</p> <p>I’ve seen two teams start new products with microservices. One spent four months before they had anything deployed — Kubernetes setup, service discovery, distributed tracing, a CI/CD pipeline for twelve repos, and debates about how to split domains they hadn’t fully understood yet. They ran out of runway. The other team I worked on started with a monolith, shipped their first real user feature in three weeks, and only extracted services when the actual pain of growth made the benefit obvious. We’re still running that system, and it handles tens of millions of requests a day.</p> </article> <article> <h1>Lesson 14: derive Is Your Best Friend — The macros you should always use</h1> <p>Thu, 02 May 2024 10:30:00 +0000</p> <p>I review a lot of Rust code, and one of my biggest pet peeves is types without <code>#[derive(Debug)]</code>. You hit an error, you try to print the value, and you get that lovely message: “MyStruct doesn’t implement Debug.” Then you have to go add it, recompile, and try again.</p> <p>Just derive it from the start. Derive liberally. Your future self will thank you.</p> <hr> <h2 id="the-derives-you-should-almost-always-use">The Derives You Should Almost Always Use</h2> <p>Here’s my standard starting point for any struct or enum:</p> </article> <article> <h1>Lesson 23: The Type System — Types, aliases, conversions, and embedding</h1> <p>Thu, 02 May 2024 00:00:00 +0000</p> <p>When I first came to Go from Python, the type system felt like a lot of ceremony. Why can’t I just use an <code>int</code> where a <code>float64</code> is expected? Why do I need to define a whole new type just to give an integer more meaning? The answers to those questions turned out to be one of the things I now appreciate most about Go. Types aren’t bureaucracy — they’re a way of making your code explain itself.</p> </article> <article> <h1>Lesson 2: Sorting in Practice — When to sort and why TimSort won</h1> <p>Wed, 01 May 2024 00:00:00 +0000</p> <p>Sorting is one of those topics that feels like a solved problem until you actually need to care about it. Every language ships a standard sort. You call it, it works, you move on. But I have run into subtle production bugs caused by not understanding what the sort is actually doing — unstable sorts breaking tie-breaking logic, sorts on large datasets consuming unexpected memory, and sort comparators with subtle bugs that triggered Go’s sort to panic.</p> </article> <article> <h1>Lesson 13: Display and Debug — Formatting done right</h1> <p>Tue, 30 Apr 2024 18:45:00 +0000</p> <p>Pop quiz: what’s the difference between <code>{}</code> and <code>{:?}</code> in a <code>println!</code>? If your answer is “one looks prettier,” you’re not wrong — but you’re missing the bigger picture.</p> <p><code>Display</code> and <code>Debug</code> serve fundamentally different audiences. <code>Display</code> is for humans — end users, log readers, UI consumers. <code>Debug</code> is for developers — it’s what you see in error messages, test failures, and debug sessions. Conflating the two leads to types that are either too verbose for users or too opaque for debugging.</p> </article> <article> <h1>Lesson 12: Designing Error Types — thiserror vs anyhow</h1> <p>Mon, 29 Apr 2024 12:18:00 +0000</p> <p>I’ve seen two extremes in Rust error handling. On one end: <code>Box<dyn std::error::Error></code> everywhere, a stringly-typed mess where you can’t distinguish a network timeout from a parse failure. On the other end: 47 custom error types with hand-written <code>Display</code> and <code>From</code> implementations, an over-engineered cathedral of boilerplate.</p> <p>The right answer is somewhere in the middle. And the two crates that get you there are <code>thiserror</code> and <code>anyhow</code>.</p> <hr> <h2 id="the-wrong-ways">The Wrong Ways</h2> <h3 id="wrong-way-1-string-errors">Wrong Way #1: String Errors</h3> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">parse_config</span>(input: <span style="color:#66d9ef">&</span><span style="color:#66d9ef">str</span>) -> Result<span style="color:#f92672"><</span><span style="color:#66d9ef">u16</span>, String<span style="color:#f92672">></span> { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> port: <span style="color:#66d9ef">u16</span> <span style="color:#f92672">=</span> input.parse().map_err(<span style="color:#f92672">|</span>e<span style="color:#f92672">|</span> <span style="color:#a6e22e">format!</span>(<span style="color:#e6db74">"bad port: </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, e))<span style="color:#f92672">?</span>; </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">if</span> port <span style="color:#f92672"><</span> <span style="color:#ae81ff">1024</span> { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">return</span> Err(<span style="color:#e6db74">"port must be >= 1024"</span>.to_string()); </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> Ok(port) </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>The caller gets a <code>String</code>. What can they do with it? Print it. That’s about it. They can’t match on error variants, can’t programmatically decide how to handle different failures, can’t distinguish between “bad port” and “port too low.” It’s a dead end.</p> </article> <article> <h1>Lesson 1: TCP Deep Dive — Three-way handshake, congestion, Nagle</h1> <p>Mon, 29 Apr 2024 00:00:00 +0000</p> <p>I used to treat TCP as a black box. Data goes in one side, data comes out the other — reliably, in order, no duplicates. That was all I needed to know, right? Then I started debugging latency spikes in a payment service and spent three days chasing a 200ms tail latency that turned out to be Nagle’s algorithm fighting with delayed ACKs. After that, I stopped treating TCP as a black box.</p> </article> <article> <h1>Lesson 2: Linked Lists — Almost never the right choice</h1> <p>Sun, 28 Apr 2024 00:00:00 +0000</p> <p>Linked lists are the most over-taught data structure in computer science and the most under-used structure in production systems. I’ve reviewed hundreds of pull requests across distributed systems codebases, and I can count on one hand the times a linked list was genuinely the right call.</p> <p>That said, understanding why linked lists are usually wrong teaches you something profound about how computers actually work. And there are a handful of situations where they’re exactly right — and when those situations come up, you need to recognize them fast.</p> </article> <article> <h1>Lesson 11: Cow — Clone on write for flexible APIs</h1> <p>Sat, 27 Apr 2024 15:33:00 +0000</p> <p>There’s a function signature dilemma that every Rust developer hits: should this function return <code>&str</code> or <code>String</code>? If you return <code>&str</code>, you avoid allocation — but sometimes you <em>need</em> to create a new string. If you return <code>String</code>, you allocate every time — even when you don’t need to.</p> <p><code>Cow</code> says: “Why not both?”</p> <p>The name stands for “Clone on Write,” and it’s one of those types that seems weird until you use it — and then you wonder how you lived without it.</p> </article> <article> <h1>Lesson 22: File I/O — Reading and writing files the Go way</h1> <p>Fri, 26 Apr 2024 00:00:00 +0000</p> <p>At some point every program needs to persist something — a config file, a log, a data export. File I/O is one of those topics that sounds tedious but is genuinely satisfying once it clicks. Go gives you a few different layers to work with, from the low-level <code>os</code> package to convenient one-liners. I’ll show you all of them so you can pick the right tool for the job.</p> <hr> <h2 id="the-basics">The Basics</h2> <h3 id="reading-a-file-the-simple-way">Reading a file the simple way</h3> <p>For most cases where the file is small enough to fit in memory, <code>os.ReadFile</code> is all you need:</p> </article> <article> <h1>Lesson 10: Deref Coercion — Why &String works as &str</h1> <p>Thu, 25 Apr 2024 21:10:00 +0000</p> <p>Here’s something that confused me for weeks when I started Rust: I’d write a function that takes <code>&str</code>, and I could pass it a <code>&String</code>. I’d write a function that takes <code>&[i32]</code>, and I could pass it a <code>&Vec<i32></code>. I’d use <code>*</code> to dereference a <code>Box<T></code> and get a <code>T</code>.</p> <p>How? Why? The answer is <code>Deref</code> coercion — one of Rust’s most elegant features, and one of the most poorly explained.</p> </article> <article> <h1>Lesson 1: Processes and Threads — What Goroutines Map To</h1> <p>Thu, 25 Apr 2024 00:00:00 +0000</p> <p>When I first started using Go seriously, I accepted goroutines as “lightweight threads” without really understanding what that meant. The Go runtime creates them, schedules them, and I launch them with <code>go</code>. Then I got curious: what does the OS actually see? When I run 10,000 goroutines, does the kernel manage 10,000 things? The answer is no — and understanding why requires understanding the difference between processes, kernel threads, and userspace threads. It also explains why goroutines scale so much better than Java threads or Python threads.</p> </article> <article> <h1>Lesson 9: From and Into — Seamless type conversions</h1> <p>Wed, 24 Apr 2024 07:55:00 +0000</p> <p>The first time I saw <code>.into()</code> in Rust code, I was baffled. “Into <em>what</em>?” There was no type annotation, no explicit conversion function, just <code>.into()</code> hanging off a value like it knew exactly what to become. And somehow the compiler figured it out.</p> <p>That’s the <code>From</code>/<code>Into</code> trait pair. It’s one of the most-used patterns in idiomatic Rust, and once you understand it, your APIs will feel dramatically smoother.</p> <hr> <h2 id="the-basics-from-and-into-are-mirror-images">The Basics: <code>From</code> and <code>Into</code> Are Mirror Images</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#75715e">// If you implement From<A> for B... </span></span></span><span style="display:flex;"><span><span style="color:#66d9ef">impl</span> From<span style="color:#f92672"><</span><span style="color:#66d9ef">i32</span><span style="color:#f92672">></span> <span style="color:#66d9ef">for</span> MyType { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">from</span>(value: <span style="color:#66d9ef">i32</span>) -> <span style="color:#a6e22e">Self</span> { </span></span><span style="display:flex;"><span> MyType(value) </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#75715e">// ...you get Into<B> for A for free </span></span></span><span style="display:flex;"><span><span style="color:#66d9ef">let</span> x: <span style="color:#a6e22e">MyType</span> <span style="color:#f92672">=</span> <span style="color:#ae81ff">42.</span>into(); </span></span></code></pre></div><p><strong>Always implement <code>From</code>, never <code>Into</code> directly.</strong> The standard library provides a blanket implementation: if <code>From<A></code> exists for <code>B</code>, then <code>Into<B></code> is automatically available for <code>A</code>. Implementing <code>Into</code> directly doesn’t give you the reverse.</p> </article> <article> <h1>Lesson 8: The Builder Pattern in Rust — Ergonomic construction</h1> <p>Mon, 22 Apr 2024 19:42:00 +0000</p> <p>Every Rust dev eventually runs into the “struct with 12 fields” problem. You’ve got a configuration type. Some fields are required, some are optional, some have sensible defaults. In Java, you’d use a Builder. In Python, you’d use keyword arguments. In Go, you’d use functional options.</p> <p>In Rust? You have options. And one of them is clearly better than the rest.</p> <hr> <h2 id="the-problem-constructor-explosion">The Problem: Constructor Explosion</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">ServerConfig</span> { </span></span><span style="display:flex;"><span> host: String, </span></span><span style="display:flex;"><span> port: <span style="color:#66d9ef">u16</span>, </span></span><span style="display:flex;"><span> max_connections: <span style="color:#66d9ef">usize</span>, </span></span><span style="display:flex;"><span> timeout_secs: <span style="color:#66d9ef">u64</span>, </span></span><span style="display:flex;"><span> tls_enabled: <span style="color:#66d9ef">bool</span>, </span></span><span style="display:flex;"><span> log_level: String, </span></span><span style="display:flex;"><span> workers: <span style="color:#66d9ef">usize</span>, </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#75715e">// This is painful </span></span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> config <span style="color:#f92672">=</span> ServerConfig { </span></span><span style="display:flex;"><span> host: String::from(<span style="color:#e6db74">"0.0.0.0"</span>), </span></span><span style="display:flex;"><span> port: <span style="color:#ae81ff">8080</span>, </span></span><span style="display:flex;"><span> max_connections: <span style="color:#ae81ff">1000</span>, </span></span><span style="display:flex;"><span> timeout_secs: <span style="color:#ae81ff">30</span>, </span></span><span style="display:flex;"><span> tls_enabled: <span style="color:#a6e22e">false</span>, </span></span><span style="display:flex;"><span> log_level: String::from(<span style="color:#e6db74">"info"</span>), </span></span><span style="display:flex;"><span> workers: <span style="color:#ae81ff">4</span>, </span></span><span style="display:flex;"><span> }; </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>Every field must be specified. There’s no concept of “default.” If you add a new field later, every construction site breaks. And callers have no idea which values are “important” and which are “just use the default.”</p> </article> <article> <h1>Lesson 1: How a Query Executes — Parser to Planner to Disk</h1> <p>Mon, 22 Apr 2024 00:00:00 +0000</p> <p>Every time I call <code>db.QueryContext(ctx, "SELECT * FROM orders WHERE user_id = $1", userID)</code> in Go, I used to think the database just “found” the rows. It wasn’t until I started debugging a production slowdown — a query that was fast for months and then suddenly wasn’t — that I actually traced what happens between the moment my application hands off that SQL string and the moment rows come back. Understanding that pipeline changed how I write queries, design schemas, and diagnose performance problems.</p> </article> <article> <h1>Lesson 7: The Newtype Pattern — Type safety for free</h1> <p>Sun, 21 Apr 2024 13:15:00 +0000</p> <p>True story: a Mars orbiter was lost because one team used pounds and another used newtons. Same numeric type, different semantic meanings. $327 million, gone.</p> <p>You’d think we’d have learned. But I still see codebases where user IDs, product IDs, and order IDs are all <code>i64</code>. Where distances are <code>f64</code> whether they’re meters or feet. Where an email address is just a <code>String</code> that you hope someone validated.</p> <p>The newtype pattern fixes this. It gives you type safety with zero runtime cost.</p> </article> <article> <h1>Lesson 21: JSON and HTTP — Reading and writing the web's language</h1> <p>Sun, 21 Apr 2024 00:00:00 +0000</p> <p>Almost every program I write these days talks to something over HTTP — a third-party API, a database service, a webhook. And almost everything speaks JSON. So learning how Go handles JSON and HTTP isn’t an advanced topic; it’s one of the most practical skills you can pick up early.</p> <p>In this lesson I’ll walk you through converting Go structs to JSON and back, decoding JSON from an API response, and making real HTTP requests — all using only Go’s standard library. No third-party packages needed.</p> </article> <article> <h1>Lesson 1: How the Internet Works — DNS, TCP, HTTP, TLS in 15 Minutes</h1> <p>Sat, 20 Apr 2024 00:00:00 +0000</p> <p>Every system design interview starts with the same silent assumption: you already know how the internet works. Interviewers won’t ask you to explain DNS. But when you confidently say “the client calls the API” without being able to say what actually happens between those words, the cracks show up in your design. Understanding the layers — DNS, TCP, HTTP, TLS — isn’t trivia. It’s the mental model that tells you where latency hides, why connections are expensive, and what breaks under load.</p> </article> <article> <h1>Lesson 6: The Typestate Pattern — Compile-time state machines</h1> <p>Fri, 19 Apr 2024 10:28:00 +0000</p> <p>I once spent two days debugging a production issue where someone called <code>.send()</code> on an HTTP request builder <em>before</em> setting the URL. The code compiled fine — it was a runtime error that only surfaced under specific conditions. In Python. In Java. In Go. This kind of bug is everywhere.</p> <p>In Rust, you can make it literally impossible to compile. The typestate pattern encodes state transitions into the type system. If the state machine says you can’t send before setting a URL, the compiler enforces it. Not with runtime checks. Not with assertions. With <em>types</em>.</p> </article> <article> <h1>Lesson 25: Where to Go from Here — Your Rust learning path</h1> <p>Thu, 18 Apr 2024 18:00:00 +0000</p> <p>You’ve made it through 24 lessons. You understand ownership, borrowing, structs, enums, traits, generics, error handling, closures, iterators, and file I/O. That’s not nothing — that’s the foundation of every Rust program ever written. But foundations are for building on. Here’s where to go from here.</p> <h2 id="what-you-know-now">What You Know Now</h2> <p>Take a second to appreciate what you’ve learned. You can:</p> <ul> <li>Set up a Rust project with Cargo</li> <li>Write functions with proper ownership and borrowing</li> <li>Model data with structs and enums</li> <li>Handle errors with Result and the <code>?</code> operator</li> <li>Use collections: Vec, HashMap, HashSet</li> <li>Write generic code with trait bounds</li> <li>Process data with iterators and closures</li> <li>Test your code with <code>#[test]</code></li> <li>Read and write files</li> </ul> <p>That’s a real skill set. You can build useful things right now. Before diving into advanced topics, I strongly recommend you build something. Nothing fancy — a command-line tool, a file processor, a simple data structure. The gap between “I understand the concepts” and “I can write a program” is only bridged by practice.</p> </article> <article> <h1>Lesson 5: Iterator Chains Over Manual Loops — Functional Rust</h1> <p>Thu, 18 Apr 2024 16:03:00 +0000</p> <p>I used to write Rust like I was still writing C — <code>for</code> loops everywhere, mutable accumulators, index variables. The code worked, but it was <em>loud</em>. Five lines to express what should be one. Then I started using iterator chains, and honestly? I’m never going back.</p> <p>Iterator chains aren’t just syntactic sugar. They’re often <em>faster</em> than hand-written loops because the compiler can optimize them better. Zero-cost abstractions in action.</p> <hr> <h2 id="the-imperative-way-vs-the-idiomatic-way">The Imperative Way vs The Idiomatic Way</h2> <p>Here’s a task: given a list of strings, find all that start with “error:”, strip the prefix, trim whitespace, and collect the results.</p> </article> <article> <h1>Lesson 1: Big-O Thinking — Will this scale to 1M records?</h1> <p>Thu, 18 Apr 2024 00:00:00 +0000</p> <p>I spent two years writing Go services before I really internalized Big-O. Not because I didn’t know the notation — every CS course teaches you to recite O(n log n) — but because I never tied it to a real decision I had to make in production. It clicked for me the day a coworker asked, “will this work when we have a million users?” and I had no honest answer.</p> </article> <article> <h1>Lesson 20: Testing in Go — Every Go file gets a test file</h1> <p>Wed, 17 Apr 2024 00:00:00 +0000</p> <p>I used to think testing was something you did after you finished writing code — a checkbox you ticked before committing. Go changed that attitude for me, not by lecturing me about best practices, but by making testing so straightforward that there was no excuse not to do it. The tooling is built in, the conventions are clear, and writing a test in Go takes about as long as writing the function itself. After a few weeks with Go, I started writing tests alongside my code, then slightly before it. The feedback loop became addictive.</p> </article> <article> <h1>Lesson 24: Reading and Writing Files — Real I/O in Rust</h1> <p>Tue, 16 Apr 2024 13:45:00 +0000</p> <p>Every tutorial teaches you to manipulate data in memory, but real programs read from files and write to files. Rust’s file I/O is built on the same ownership and error handling principles you’ve been learning — and once you see how <code>Result</code>, iterators, and traits come together, the entire language design starts to feel cohesive.</p> <h2 id="reading-a-file--the-quick-way">Reading a File — The Quick Way</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">use</span> std::fs; </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">match</span> fs::read_to_string(<span style="color:#e6db74">"hello.txt"</span>) { </span></span><span style="display:flex;"><span> Ok(content) <span style="color:#f92672">=></span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"File contents:</span><span style="color:#ae81ff">\n</span><span style="color:#e6db74">{content}</span><span style="color:#e6db74">"</span>), </span></span><span style="display:flex;"><span> Err(e) <span style="color:#f92672">=></span> <span style="color:#a6e22e">eprintln!</span>(<span style="color:#e6db74">"Error reading file: </span><span style="color:#e6db74">{e}</span><span style="color:#e6db74">"</span>), </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p><code>fs::read_to_string</code> reads the entire file into a <code>String</code>. It returns <code>Result<String, io::Error></code> — because file operations can fail (file doesn’t exist, permission denied, disk error, etc.).</p> </article> <article> <h1>Lesson 4: if let and while let — Concise pattern matching</h1> <p>Tue, 16 Apr 2024 08:45:00 +0000</p> <p>There’s a special kind of code smell that I call “match bloat” — when you write a six-line <code>match</code> statement to handle a single variant and throw an underscore wildcard on everything else. I wrote hundreds of these before discovering that Rust has a better way.</p> <p>If you’re writing <code>match</code> just to handle one case, you’re doing too much work.</p> <hr> <h2 id="the-problem-match-bloat">The Problem: Match Bloat</h2> <p>Here’s code I see all the time, especially from developers coming from the previous lesson on <code>Option</code> and <code>Result</code>:</p> </article> <article> <h1>Lesson 1: Arrays and Memory Layout — Cache lines decide your performance</h1> <p>Mon, 15 Apr 2024 00:00:00 +0000</p> <p>I spent two years writing Go services before I genuinely understood why iterating over a two-dimensional slice in the wrong order could tank my throughput by 5x. It wasn’t a bug. It wasn’t a bad algorithm. It was cache lines.</p> <p>Arrays are the first data structure everyone learns and the last one most engineers actually understand. This is my attempt to fix that — not with theory, but with the reasoning that makes you a better systems engineer.</p> </article> <article> <h1>Lesson 3: Option and Result Are Your Control Flow — Stop using sentinel values</h1> <p>Sun, 14 Apr 2024 11:22:00 +0000</p> <p>I once inherited a C codebase where <code>-1</code> meant “not found,” <code>0</code> meant “error,” and <code>NULL</code> meant… well, it depended on the function. Sometimes it meant “empty,” sometimes “uninitialized,” sometimes “we ran out of memory.” The codebase had roughly 40 unique sentinel values across different modules, and half the bugs were someone forgetting which magic number meant what.</p> <p>Rust looked at that mess and said: “How about we just… don’t.”</p> </article> <article> <h1>Lesson 23: Writing Your First Tests — #[test] and assert!</h1> <p>Sun, 14 Apr 2024 11:00:00 +0000</p> <p>I have a rule: I won’t merge code without tests. Not because I’m a purist — because I’ve been burned too many times. Rust makes testing so frictionless that there’s no excuse to skip it. Tests live in the same file as your code. They run with one command. The tooling just works.</p> <h2 id="your-first-test">Your First Test</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">add</span>(a: <span style="color:#66d9ef">i32</span>, b: <span style="color:#66d9ef">i32</span>) -> <span style="color:#66d9ef">i32</span> { </span></span><span style="display:flex;"><span> a <span style="color:#f92672">+</span> b </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#75715e">#[cfg(test)]</span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">mod</span> tests { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">use</span> <span style="color:#66d9ef">super</span>::<span style="color:#f92672">*</span>; </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#75715e">#[test]</span> </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">test_add</span>() { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">assert_eq!</span>(add(<span style="color:#ae81ff">2</span>, <span style="color:#ae81ff">3</span>), <span style="color:#ae81ff">5</span>); </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#75715e">#[test]</span> </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">test_add_negative</span>() { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">assert_eq!</span>(add(<span style="color:#f92672">-</span><span style="color:#ae81ff">1</span>, <span style="color:#ae81ff">1</span>), <span style="color:#ae81ff">0</span>); </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#75715e">#[test]</span> </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">test_add_zero</span>() { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">assert_eq!</span>(add(<span style="color:#ae81ff">0</span>, <span style="color:#ae81ff">0</span>), <span style="color:#ae81ff">0</span>); </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>Run with <code>cargo test</code>:</p> </article> <article> <h1>Lesson 4: Stack — Last In, First Out Solves More Than You Think</h1> <p>Sat, 13 Apr 2024 00:00:00 +0000</p> <p>The stack is one of those data structures that seems too simple to be interesting — push, pop, peek, done. Then you sit in an interview, stare at a problem about brackets or expression evaluation, and realize you’re reaching for exactly this tool. I’ve seen candidates overcomplicate parenthesis validation with counters and flags when a stack makes it four lines of logic. I’ve also seen the reverse: candidates who knew the stack solution for valid parentheses but couldn’t extend the thinking to a harder variant.</p> </article> <article> <h1>Lesson 2: Borrow Strategically — &T, &mut T, and when to clone</h1> <p>Fri, 12 Apr 2024 14:37:00 +0000</p> <p>A colleague once showed me their Rust code where every function parameter was <code>String</code> — never <code>&str</code>, never <code>&String</code>. When I asked why, they said “the borrow checker kept yelling at me, so I just take ownership of everything.” Classic.</p> <p>I get it. The borrow checker can feel like an overzealous hall monitor. But once you understand the borrowing rules — really understand them — you’ll realize it’s not restricting you. It’s showing you a better design.</p> </article> <article> <h1>Lesson 22: Iterators — Lazy, composable data processing</h1> <p>Fri, 12 Apr 2024 09:30:00 +0000</p> <p>I once profiled a Go service and found it was spending 40% of CPU time allocating intermediate slices in a data pipeline. Each transformation created a new slice, copied data, processed it, then created another. In Rust, iterator chains do the same transformation with zero intermediate allocations. The data flows through the pipeline element by element, transformed in place. That’s not just elegant — it’s measurably faster.</p> <h2 id="the-iterator-trait">The Iterator Trait</h2> <p>At its core, an iterator is any type that implements the <code>Iterator</code> trait:</p> </article> <article> <h1>Lesson 19: Context — Passing deadlines and cancellation through your code</h1> <p>Fri, 12 Apr 2024 00:00:00 +0000</p> <p>There’s a moment in every Go developer’s journey when they realize that starting an operation isn’t the hard part — stopping it cleanly is. What happens when a user cancels a request? What happens when a database query takes 30 seconds instead of 300 milliseconds? Without a way to communicate “stop what you’re doing,” those goroutines keep running, consuming resources for something that no longer matters.</p> <p>That’s the problem <code>context</code> solves. It gives you a standard way to carry a cancellation signal, a deadline, and a small amount of request-scoped data through your entire call stack. Once you understand it, you’ll see why the Go standard library passes it as the first parameter to almost every function that does I/O.</p> </article> <article> <h1>Lesson 21: Closures — Functions that capture</h1> <p>Wed, 10 Apr 2024 12:15:00 +0000</p> <p>Closures are where Rust stops feeling like a systems language and starts feeling like a functional one. You’ve already been using them — every time you passed <code>|x| x * 2</code> to <code>.map()</code> or <code>|a, b| a.cmp(b)</code> to <code>.sort_by()</code>, that was a closure. Time to understand what’s actually happening under the hood.</p> <h2 id="what-is-a-closure">What Is a Closure?</h2> <p>A closure is an anonymous function that can capture variables from its surrounding scope:</p> </article> <article> <h1>Lesson 1: Think in Ownership — Not pointers</h1> <p>Wed, 10 Apr 2024 09:14:00 +0000</p> <p>I spent three months fighting the borrow checker before I realized the problem wasn’t the borrow checker — it was me. I kept thinking in C++ pointers and Java references. Every <code>String</code> was just “data on the heap.” Every function call was “passing a reference.” And every compiler error felt like Rust was being unreasonable.</p> <p>It wasn’t. I was just thinking about memory the wrong way.</p> <hr> <h2 id="the-cjava-mental-model-and-why-it-fails">The C++/Java Mental Model (And Why It Fails)</h2> <p>If you come from C++, your brain maps everything to raw pointers, smart pointers, or references. If you come from Java/Python/Go, everything is a reference behind the scenes — you never think about who owns what, because the GC handles it.</p> </article> <article> <h1>Lesson 1: Design YouTube — Video upload, transcoding, streaming at scale</h1> <p>Tue, 09 Apr 2024 00:00:00 +0000</p> <p>YouTube serves over 500 hours of video uploaded every minute and delivers billions of views per day. When I first studied this problem seriously, I made the mistake of treating it as a simple “upload file, store it, serve it” exercise. It isn’t. The interesting engineering is in what happens between the moment a creator hits upload and the moment a viewer’s video starts playing seamlessly on a 3G connection in rural India. That gap is where the system design lives.</p> </article> <article> <h1>Lesson 20: Generics — Writing code that works for any type</h1> <p>Mon, 08 Apr 2024 20:00:00 +0000</p> <p>I used to think generics were fancy academic stuff that you’d rarely need in practice. Then I wrote my third function that was identical to a previous one except it operated on <code>f64</code> instead of <code>i32</code>. Generics aren’t luxury features — they’re how you stop writing the same function five times for five different types.</p> <h2 id="the-problem-generics-solve">The Problem Generics Solve</h2> <p>Without generics, you write duplicate code:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">largest_i32</span>(list: <span style="color:#66d9ef">&</span>[<span style="color:#66d9ef">i32</span>]) -> <span style="color:#66d9ef">&</span><span style="color:#66d9ef">i32</span> { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> <span style="color:#66d9ef">mut</span> largest <span style="color:#f92672">=</span> <span style="color:#f92672">&</span>list[<span style="color:#ae81ff">0</span>]; </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">for</span> item <span style="color:#66d9ef">in</span> list { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">if</span> item <span style="color:#f92672">></span> largest { </span></span><span style="display:flex;"><span> largest <span style="color:#f92672">=</span> item; </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> largest </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">largest_f64</span>(list: <span style="color:#66d9ef">&</span>[<span style="color:#66d9ef">f64</span>]) -> <span style="color:#66d9ef">&</span><span style="color:#66d9ef">f64</span> { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> <span style="color:#66d9ef">mut</span> largest <span style="color:#f92672">=</span> <span style="color:#f92672">&</span>list[<span style="color:#ae81ff">0</span>]; </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">for</span> item <span style="color:#66d9ef">in</span> list { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">if</span> item <span style="color:#f92672">></span> largest { </span></span><span style="display:flex;"><span> largest <span style="color:#f92672">=</span> item; </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> largest </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> ints <span style="color:#f92672">=</span> <span style="color:#a6e22e">vec!</span>[<span style="color:#ae81ff">34</span>, <span style="color:#ae81ff">50</span>, <span style="color:#ae81ff">25</span>, <span style="color:#ae81ff">100</span>, <span style="color:#ae81ff">65</span>]; </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> floats <span style="color:#f92672">=</span> <span style="color:#a6e22e">vec!</span>[<span style="color:#ae81ff">3.4</span>, <span style="color:#ae81ff">5.0</span>, <span style="color:#ae81ff">2.5</span>, <span style="color:#ae81ff">10.0</span>, <span style="color:#ae81ff">6.5</span>]; </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"Largest int: </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, largest_i32(<span style="color:#f92672">&</span>ints)); </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"Largest float: </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, largest_f64(<span style="color:#f92672">&</span>floats)); </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>These functions are identical except for the type. Generics let you write it once:</p> </article> <article> <h1>Lesson 19: Traits — Your first abstraction</h1> <p>Sun, 07 Apr 2024 15:45:00 +0000</p> <p>Traits are the mechanism I miss most when I leave Rust. They’re interfaces without inheritance, type classes without the math, and the foundation of every abstraction in the language. If structs define what data <em>is</em>, traits define what data <em>does</em>.</p> <h2 id="what-is-a-trait">What Is a Trait?</h2> <p>A trait defines a set of methods that a type can implement:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">trait</span> Greet { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">hello</span>(<span style="color:#f92672">&</span>self) -> String; </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Person</span> { </span></span><span style="display:flex;"><span> name: String, </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Robot</span> { </span></span><span style="display:flex;"><span> id: <span style="color:#66d9ef">u32</span>, </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">impl</span> Greet <span style="color:#66d9ef">for</span> Person { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">hello</span>(<span style="color:#f92672">&</span>self) -> String { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">format!</span>(<span style="color:#e6db74">"Hi, I'm </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">!"</span>, self.name) </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">impl</span> Greet <span style="color:#66d9ef">for</span> Robot { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">hello</span>(<span style="color:#f92672">&</span>self) -> String { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">format!</span>(<span style="color:#e6db74">"UNIT-</span><span style="color:#e6db74">{}</span><span style="color:#e6db74"> OPERATIONAL"</span>, self.id) </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> person <span style="color:#f92672">=</span> Person { name: String::from(<span style="color:#e6db74">"Alice"</span>) }; </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> robot <span style="color:#f92672">=</span> Robot { id: <span style="color:#ae81ff">42</span> }; </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"</span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, person.hello()); </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"</span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, robot.hello()); </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>The trait <code>Greet</code> declares that any implementing type must have a <code>hello</code> method. <code>Person</code> and <code>Robot</code> each provide their own implementation. Different types, same interface.</p> </article> <article> <h1>Lesson 18: The sync Package — Coordination tools for concurrent code</h1> <p>Sat, 06 Apr 2024 00:00:00 +0000</p> <p>Goroutines make concurrency easy to start, but easy to start isn’t the same as easy to get right. The first time I ran multiple goroutines that touched shared data, I got a data race — a situation where two goroutines read and write the same variable at the same time, producing unpredictable results. The Go race detector caught it immediately, but I still had to understand <em>how to fix it</em>.</p> </article> <article> <h1>Lesson 18: Crates, Cargo.toml, and Dependencies — The Rust ecosystem</h1> <p>Fri, 05 Apr 2024 10:30:00 +0000</p> <p>The first time I added a dependency in Rust, I was shocked. Add one line to Cargo.toml, run <code>cargo build</code>, and it downloads, compiles, and links everything automatically. Coming from C++ where dependency management is a special circle of hell, Cargo felt like cheating.</p> <h2 id="what-is-a-crate">What Is a Crate?</h2> <p>A crate is a compilation unit in Rust — the smallest amount of code the compiler considers at a time. There are two kinds:</p> </article> <article> <h1>Lesson 17: Modules — Organizing your code</h1> <p>Wed, 03 Apr 2024 14:00:00 +0000</p> <p>Rust’s module system confused me for longer than I’d like to admit. I came from Go, where packages map directly to directories. Rust’s module system is more flexible — and more confusing as a result. But once you understand the mental model, it’s actually quite elegant. The key insight: the file system doesn’t define the module tree. You do.</p> <h2 id="modules-in-a-single-file">Modules in a Single File</h2> <p>The simplest case — modules defined inline:</p> </article> <article> <h1>Lesson 17: Go Modules — Managing dependencies without pain</h1> <p>Tue, 02 Apr 2024 00:00:00 +0000</p> <p>Before Go modules existed, managing dependencies was genuinely painful. People used all sorts of third-party tools with their own conventions, and getting a new contributor up and running on a project could eat half a day. I started learning Go after modules became the standard, and I took for granted how smooth the experience was — until I read the old blog posts describing what came before. It made me appreciate <code>go mod init</code> in a way that’s hard to describe.</p> </article> <article> <h1>Lesson 16: Result and the ? Operator — Errors as values</h1> <p>Mon, 01 Apr 2024 08:45:00 +0000</p> <p>Exception-based error handling has a fundamental flaw: you can’t tell by looking at a function signature whether it might throw. Go fixed this by returning <code>(value, error)</code> tuples, but then you’re back to forgetting to check the error. Rust’s <code>Result</code> type gets it right — errors are values, and the type system makes them impossible to ignore.</p> <h2 id="the-result-type">The Result Type</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#75715e">// Built into the language: </span></span></span><span style="display:flex;"><span><span style="color:#75715e">// enum Result<T, E> { </span></span></span><span style="display:flex;"><span><span style="color:#75715e">// Ok(T), </span></span></span><span style="display:flex;"><span><span style="color:#75715e">// Err(E), </span></span></span><span style="display:flex;"><span><span style="color:#75715e">// } </span></span></span></code></pre></div><p><code>Result<T, E></code> is either <code>Ok(T)</code> (success with a value) or <code>Err(E)</code> (failure with an error). You’ve seen <code>Option<T></code> — <code>Result</code> is similar but carries error information when something goes wrong.</p> </article> <article> <h1>Lesson 15: Vec, HashMap, and HashSet — The collections you'll use daily</h1> <p>Sat, 30 Mar 2024 11:15:00 +0000</p> <p>In my experience, about 80% of all data structures in real programs are either lists or key-value maps. Rust nails both of them. <code>Vec</code> and <code>HashMap</code> are fast, safe, and ergonomic — and once you know these two plus <code>HashSet</code>, you can build almost anything.</p> <h2 id="vec--the-dynamic-array">Vec — The Dynamic Array</h2> <p><code>Vec<T></code> is Rust’s growable array. It stores elements contiguously on the heap, like <code>ArrayList</code> in Java or <code>std::vector</code> in C++.</p> </article> <article> <h1>Lesson 14: Methods and Associated Functions — impl blocks explained</h1> <p>Thu, 28 Mar 2024 17:30:00 +0000</p> <p>In most object-oriented languages, data and behavior are bundled together inside classes. Rust separates them — you define data with <code>struct</code> (or <code>enum</code>) and attach behavior with <code>impl</code> blocks. This separation is cleaner than it sounds. You can add methods to a type from anywhere, not just its original definition. And there’s no inheritance tax.</p> <h2 id="your-first-impl-block">Your First impl Block</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#75715e">#[derive(Debug)]</span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">Rectangle</span> { </span></span><span style="display:flex;"><span> width: <span style="color:#66d9ef">f64</span>, </span></span><span style="display:flex;"><span> height: <span style="color:#66d9ef">f64</span>, </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">impl</span> Rectangle { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">area</span>(<span style="color:#f92672">&</span>self) -> <span style="color:#66d9ef">f64</span> { </span></span><span style="display:flex;"><span> self.width <span style="color:#f92672">*</span> self.height </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">perimeter</span>(<span style="color:#f92672">&</span>self) -> <span style="color:#66d9ef">f64</span> { </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">2.0</span> <span style="color:#f92672">*</span> (self.width <span style="color:#f92672">+</span> self.height) </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">is_square</span>(<span style="color:#f92672">&</span>self) -> <span style="color:#66d9ef">bool</span> { </span></span><span style="display:flex;"><span> (self.width <span style="color:#f92672">-</span> self.height).abs() <span style="color:#f92672"><</span> <span style="color:#66d9ef">f64</span>::<span style="color:#66d9ef">EPSILON</span> </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> rect <span style="color:#f92672">=</span> Rectangle { width: <span style="color:#ae81ff">10.0</span>, height: <span style="color:#ae81ff">5.0</span> }; </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"Area: </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, rect.area()); </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"Perimeter: </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, rect.perimeter()); </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"Is square: </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, rect.is_square()); </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>The <code>impl Rectangle</code> block defines methods for the <code>Rectangle</code> type. Inside the block, <code>&self</code> is a reference to the instance the method is called on. It’s equivalent to <code>self: &Self</code>, where <code>Self</code> is an alias for <code>Rectangle</code>.</p> </article> <article> <h1>Lesson 3: Sliding Window — Fixed or Variable, the Window Always Moves Right</h1> <p>Thu, 28 Mar 2024 00:00:00 +0000</p> <p>Sliding window problems have a tell: the problem asks about a contiguous subarray or substring, and there’s a constraint that makes the brute force obvious but slow. When I was interviewing at a mid-size fintech that fancied itself FAANG-adjacent, I got a stock price problem in my first round. I almost panicked — “is this dynamic programming?” It wasn’t. It was a sliding window in disguise, and once I saw it, the solution wrote itself in about four minutes.</p> </article> <article> <h1>Lesson 16: Packages and Imports — Organizing code like a professional</h1> <p>Wed, 27 Mar 2024 00:00:00 +0000</p> <p>Every Go program I’ve written has taught me the same lesson over and over: good code isn’t just about what you write inside functions — it’s about how you organize those functions in the first place. When I started with Go, I crammed everything into one file. It worked, until it didn’t. By the time I had a few hundred lines, I couldn’t find anything. That’s when packages stopped being an abstract concept and became something I genuinely needed.</p> </article> <article> <h1>Lesson 13: Pattern Matching — The match superpower</h1> <p>Tue, 26 Mar 2024 09:45:00 +0000</p> <p>Pattern matching ruined switch statements for me. After using <code>match</code> in Rust for a few months, going back to C-style switch/case feels like using a butter knife to do surgery. The compiler checks that you’ve covered every case. It destructures data inline. It does not fall through. It is, hands down, the most elegant control flow construct I’ve ever used.</p> <h2 id="basic-match">Basic match</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> x <span style="color:#f92672">=</span> <span style="color:#ae81ff">3</span>; </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">match</span> x { </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">1</span> <span style="color:#f92672">=></span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"one"</span>), </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">2</span> <span style="color:#f92672">=></span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"two"</span>), </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">3</span> <span style="color:#f92672">=></span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"three"</span>), </span></span><span style="display:flex;"><span> _ <span style="color:#f92672">=></span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"something else"</span>), </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p><code>_</code> is the catch-all pattern — it matches anything. Think of it as the <code>default</code> case in a switch statement, except it’s mandatory when the other arms don’t cover all possibilities.</p> </article> <article> <h1>Lesson 12: Enums and Option — Null safety by design</h1> <p>Mon, 25 Mar 2024 12:00:00 +0000</p> <p>Tony Hoare called null his “billion-dollar mistake.” He invented it in 1965 and has publicly apologized for it multiple times since. Rust took him seriously. There is no null in Rust — and the replacement is so much better that going back to languages with null feels like giving up a superpower.</p> <h2 id="basic-enums">Basic Enums</h2> <p>At their simplest, enums define a type that can be one of several variants:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#75715e">#[derive(Debug)]</span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">enum</span> <span style="color:#a6e22e">Direction</span> { </span></span><span style="display:flex;"><span> North, </span></span><span style="display:flex;"><span> South, </span></span><span style="display:flex;"><span> East, </span></span><span style="display:flex;"><span> West, </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">describe</span>(dir: <span style="color:#66d9ef">&</span><span style="color:#a6e22e">Direction</span>) -> <span style="color:#66d9ef">&</span><span style="color:#66d9ef">str</span> { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">match</span> dir { </span></span><span style="display:flex;"><span> Direction::North <span style="color:#f92672">=></span> <span style="color:#e6db74">"heading north"</span>, </span></span><span style="display:flex;"><span> Direction::South <span style="color:#f92672">=></span> <span style="color:#e6db74">"heading south"</span>, </span></span><span style="display:flex;"><span> Direction::East <span style="color:#f92672">=></span> <span style="color:#e6db74">"heading east"</span>, </span></span><span style="display:flex;"><span> Direction::West <span style="color:#f92672">=></span> <span style="color:#e6db74">"heading west"</span>, </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> d <span style="color:#f92672">=</span> Direction::North; </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"</span><span style="color:#e6db74">{:?}</span><span style="color:#e6db74">: </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, d, describe(<span style="color:#f92672">&</span>d)); </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>If this is all enums did, they’d be equivalent to C enums. Mildly useful. Not exciting.</p> </article> <article> <h1>Lesson 11: Structs — Modeling your domain</h1> <p>Sat, 23 Mar 2024 20:15:00 +0000</p> <p>I worked on a Go codebase once where someone had passed around a <code>map[string]interface{}</code> for user data. It was fine until someone misspelled “email” as “emial” and we spent half a day tracking down why emails weren’t sending. Structs are how you prevent this entire category of mistake — named fields with typed data, checked at compile time.</p> <h2 id="defining-a-struct">Defining a Struct</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">struct</span> <span style="color:#a6e22e">User</span> { </span></span><span style="display:flex;"><span> name: String, </span></span><span style="display:flex;"><span> email: String, </span></span><span style="display:flex;"><span> age: <span style="color:#66d9ef">u32</span>, </span></span><span style="display:flex;"><span> active: <span style="color:#66d9ef">bool</span>, </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> user <span style="color:#f92672">=</span> User { </span></span><span style="display:flex;"><span> name: String::from(<span style="color:#e6db74">"Alice"</span>), </span></span><span style="display:flex;"><span> email: String::from(<span style="color:#e6db74">"alice@example.com"</span>), </span></span><span style="display:flex;"><span> age: <span style="color:#ae81ff">30</span>, </span></span><span style="display:flex;"><span> active: <span style="color:#a6e22e">true</span>, </span></span><span style="display:flex;"><span> }; </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"</span><span style="color:#e6db74">{}</span><span style="color:#e6db74"> (</span><span style="color:#e6db74">{}</span><span style="color:#e6db74">) - age </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, user.name, user.email, user.age); </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>Struct names are <code>PascalCase</code>. Field names are <code>snake_case</code>. These aren’t suggestions — the compiler warns you if you deviate.</p> </article> <article> <h1>Lesson 10: Strings — String vs &str and why it matters</h1> <p>Fri, 22 Mar 2024 15:30:00 +0000</p> <p>Strings are the #1 source of confusion for Rust beginners. I see the same questions every week: “Why are there two string types?” “Why can’t I index a string?” “Why is this so much harder than in Python?” It’s not harder — it’s <em>more honest</em>. Other languages hide the complexity of text. Rust makes you deal with it.</p> <h2 id="the-two-string-types">The Two String Types</h2> <p>Rust has two main string types:</p> <ul> <li><strong><code>String</code></strong> — owned, heap-allocated, growable, mutable</li> <li><strong><code>&str</code></strong> — borrowed, a slice/view into string data, immutable (usually)</li> </ul> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> owned: String <span style="color:#f92672">=</span> String::from(<span style="color:#e6db74">"hello"</span>); <span style="color:#75715e">// heap-allocated, you own it </span></span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> borrowed: <span style="color:#66d9ef">&</span><span style="color:#66d9ef">str</span> <span style="color:#f92672">=</span> <span style="color:#e6db74">"hello"</span>; <span style="color:#75715e">// string literal, embedded in binary </span></span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"</span><span style="color:#e6db74">{owned}</span><span style="color:#e6db74"> </span><span style="color:#e6db74">{borrowed}</span><span style="color:#e6db74">"</span>); </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>The relationship between <code>String</code> and <code>&str</code> is exactly like <code>Vec<u8></code> and <code>&[u8]</code>. A <code>String</code> is a buffer you own. A <code>&str</code> is a view into someone else’s string data (or a literal baked into your binary).</p> </article> <article> <h1>Lesson 15: Select — Waiting on multiple channels at once</h1> <p>Fri, 22 Mar 2024 00:00:00 +0000</p> <p>By now you know how to create goroutines and how to communicate between them using channels. But what happens when a goroutine needs to listen to two channels at the same time? Maybe it’s waiting for work to arrive, but it also needs to stop if a timeout fires. With a single channel you’d be stuck — receiving from one blocks the other.</p> <p><code>select</code> solves this. It’s like a <code>switch</code> statement for channels. It waits until one of several channel operations is ready, then executes that case. If multiple are ready at the same time, it picks one at random.</p> </article> <article> <h1>Lesson 9: Slices — Views into data</h1> <p>Wed, 20 Mar 2024 10:45:00 +0000</p> <p>Slices clicked for me when I stopped thinking of them as a language feature and started thinking of them as a design pattern: “here’s a window into someone else’s data.” They’re one of Rust’s most elegant ideas, and you’ll use them everywhere.</p> <h2 id="what-is-a-slice">What Is a Slice?</h2> <p>A slice is a reference to a contiguous sequence of elements in a collection. It doesn’t own the data — it’s a view into data owned by something else.</p> </article> <article> <h1>Lesson 8: Borrowing and References — Sharing without giving</h1> <p>Mon, 18 Mar 2024 13:00:00 +0000</p> <p>After the last lesson, you might be thinking “so every function I call takes my data and I never see it again?” That would be terrible. Borrowing is the answer — it lets you share data without transferring ownership, and it’s where Rust’s safety guarantees really shine.</p> <h2 id="references-with-">References with &</h2> <p>A reference lets you refer to a value without owning it:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">print_length</span>(s: <span style="color:#66d9ef">&</span>String) { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"Length of '</span><span style="color:#e6db74">{}</span><span style="color:#e6db74">': </span><span style="color:#e6db74">{}</span><span style="color:#e6db74">"</span>, s, s.len()); </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> s <span style="color:#f92672">=</span> String::from(<span style="color:#e6db74">"hello"</span>); </span></span><span style="display:flex;"><span> print_length(<span style="color:#f92672">&</span>s); <span style="color:#75715e">// lend s to the function </span></span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"I still own: </span><span style="color:#e6db74">{s}</span><span style="color:#e6db74">"</span>); <span style="color:#75715e">// s is still valid </span></span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>The <code>&</code> creates a reference. <code>&s</code> doesn’t move <code>s</code> — it creates a pointer to <code>s</code> that the function can use. When the function returns, the reference goes away but <code>s</code> remains untouched.</p> </article> <article> <h1>Lesson 14: Channels — How goroutines talk to each other</h1> <p>Mon, 18 Mar 2024 00:00:00 +0000</p> <p>In the last lesson, I showed you how to run code concurrently with goroutines. But goroutines that can’t talk to each other aren’t very useful. What if one goroutine produces a result that another needs? What if you want to signal that work is done without using a <code>WaitGroup</code>? That’s where channels come in.</p> <p>Go’s guiding philosophy on concurrency is: “don’t communicate by sharing memory; share memory by communicating.” Channels are the mechanism for that. Instead of multiple goroutines reading and writing the same variable, they pass values through a channel — and the channel ensures only one goroutine handles the value at a time.</p> </article> <article> <h1>Lesson 7: Ownership — The rule that changes everything</h1> <p>Sat, 16 Mar 2024 08:30:00 +0000</p> <p>I spent three hours fighting the borrow checker on my first real Rust project. I was furious. Then I realized every single error the compiler flagged was a genuine bug — a use-after-free, a data race, a dangling reference. The compiler wasn’t being difficult. It was saving me from myself.</p> <h2 id="why-ownership-exists">Why Ownership Exists</h2> <p>In C, you allocate memory and free it manually. Forget to free? Memory leak. Free twice? Undefined behavior. Use after free? Crash (if you’re lucky) or silent corruption (if you’re not).</p> </article> <article> <h1>Lesson 6: Control Flow — if, loop, while, for — and why there's no ternary</h1> <p>Thu, 14 Mar 2024 19:10:00 +0000</p> <p>I once reviewed a pull request that had seven levels of nested if-else. In Go. The author said “the language doesn’t give me better tools.” In Rust, you’ve got <code>match</code>, labeled loops, <code>if let</code>, and blocks-as-expressions — enough to keep your code flat and readable even when the logic is complex.</p> <h2 id="if--else">if / else</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> temperature <span style="color:#f92672">=</span> <span style="color:#ae81ff">35</span>; </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">if</span> temperature <span style="color:#f92672">></span> <span style="color:#ae81ff">30</span> { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"It's hot"</span>); </span></span><span style="display:flex;"><span> } <span style="color:#66d9ef">else</span> <span style="color:#66d9ef">if</span> temperature <span style="color:#f92672">></span> <span style="color:#ae81ff">20</span> { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"It's nice"</span>); </span></span><span style="display:flex;"><span> } <span style="color:#66d9ef">else</span> { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"It's cold"</span>); </span></span><span style="display:flex;"><span> } </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>Standard stuff. No parentheses around the condition — that’s a syntax error in Rust. The braces are mandatory, even for single-line bodies. No arguing about whether to use braces. They’re required. Discussion over.</p> </article> <article> <h1>Lesson 2: Two Pointers — When One Pointer Isn't Enough</h1> <p>Thu, 14 Mar 2024 00:00:00 +0000</p> <p>One of my early interview mistakes was throwing a hash map at every array problem. It works a surprising amount of the time, but there’s a whole class of problems where you don’t need extra space at all — where the structure of the input lets two indices do the work together. Two pointers is that technique, and once you see it, you cannot unsee it.</p> <p>The pattern shows up at every company. Amazon loves it for stream-processing problems. Google uses it for geometry and partition questions. Meta favors it in string validation and deduplication. Three Sum alone has appeared in more on-site rounds than I can count.</p> </article> <article> <h1>Lesson 5: Functions, Expressions, and Statements — Everything is an expression</h1> <p>Wed, 13 Mar 2024 10:20:00 +0000</p> <p>When I first read that “everything in Rust is an expression,” I thought it was marketing fluff. It’s not. It’s a genuine design principle that affects how you write code every single day, and once you internalize it, going back to statement-heavy languages feels clunky.</p> <h2 id="defining-functions">Defining Functions</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">add</span>(a: <span style="color:#66d9ef">i32</span>, b: <span style="color:#66d9ef">i32</span>) -> <span style="color:#66d9ef">i32</span> { </span></span><span style="display:flex;"><span> a <span style="color:#f92672">+</span> b </span></span><span style="display:flex;"><span>} </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> result <span style="color:#f92672">=</span> add(<span style="color:#ae81ff">3</span>, <span style="color:#ae81ff">7</span>); </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"3 + 7 = </span><span style="color:#e6db74">{result}</span><span style="color:#e6db74">"</span>); </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>A few things to notice:</p> </article> <article> <h1>Lesson 13: Goroutines — Lightweight threads that cost almost nothing</h1> <p>Tue, 12 Mar 2024 00:00:00 +0000</p> <p>One of the first things people told me about Go was “it makes concurrency easy.” I was sceptical — concurrency is never easy. But the more I used goroutines, the more I understood what they meant. It’s not that concurrency becomes simple. It’s that the cost of starting a concurrent task drops so low that you stop avoiding it.</p> <p>In most languages, spawning a thread involves megabytes of stack memory and significant overhead. A Go goroutine starts with about 2KB of stack. You can run tens of thousands of them on a normal laptop without breaking a sweat.</p> </article> <article> <h1>Lesson 4: Variables, Mutability, and Primitive Types — Let, let mut, and the type system</h1> <p>Mon, 11 Mar 2024 16:45:00 +0000</p> <p>Coming from JavaScript, I was stunned the first time Rust refused to compile because I tried to reassign a variable. “What do you mean it’s immutable by default? Who designs a language like that?” Turns out — people who’ve debugged enough mutable state to know better.</p> <h2 id="variables-with-let">Variables with let</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#66d9ef">let</span> x <span style="color:#f92672">=</span> <span style="color:#ae81ff">5</span>; </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"x is </span><span style="color:#e6db74">{x}</span><span style="color:#e6db74">"</span>); </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p><code>let</code> creates a variable binding. It binds a name to a value. By default, that binding is <strong>immutable</strong> — you can’t change it.</p> </article> <article> <h1>Lesson 3: Hello, World — Anatomy of a Rust program</h1> <p>Sat, 09 Mar 2024 11:00:00 +0000</p> <p>The first program I ever wrote was in BASIC on a Commodore 64 emulator. Took me twenty minutes to figure out why PRINT didn’t work (I was typing PIRNT). Rust’s version of Hello World looks simple — four lines — but there’s a surprising amount of language design packed into those four lines.</p> <h2 id="the-program">The Program</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-rust" data-lang="rust"><span style="display:flex;"><span><span style="color:#66d9ef">fn</span> <span style="color:#a6e22e">main</span>() { </span></span><span style="display:flex;"><span> <span style="color:#a6e22e">println!</span>(<span style="color:#e6db74">"Hello, world!"</span>); </span></span><span style="display:flex;"><span>} </span></span></code></pre></div><p>That’s it. Three lines if you’re counting. But each piece tells you something about how Rust thinks.</p> </article> <article> <h1>Lesson 2: Installing Rust — rustup, cargo, and your first build</h1> <p>Thu, 07 Mar 2024 14:30:00 +0000</p> <p>I’ve installed Rust on maybe fifty machines at this point — Linux servers, Macs, Windows boxes, even a Raspberry Pi. The process has gotten remarkably smooth. Rustup is one of the best toolchain managers in any language ecosystem, and I say that without hesitation.</p> <h2 id="installing-rustup">Installing rustup</h2> <p>Rustup is the official Rust toolchain installer and manager. It handles downloading the compiler, updating it, and switching between versions. One command gets you everything.</p> </article> <article> <h1>Lesson 12: Error Handling — Errors are values, not exceptions</h1> <p>Wed, 06 Mar 2024 00:00:00 +0000</p> <p>The first time I wrote Go after years of Python and JavaScript, I kept waiting for the <code>try/catch</code> block. It never came. Instead, almost every function returned two values: the result, and an error. I had to check the error every single time. It felt tedious at first. After a few weeks, I realised it was one of the best design decisions in the language.</p> <p>In Go, errors are just values. They’re not special. They don’t teleport up the call stack. They sit right there, in your return value, waiting for you to deal with them.</p> </article> <article> <h1>Lesson 1: Why Rust Exists — And why you should care</h1> <p>Tue, 05 Mar 2024 09:15:00 +0000</p> <p>I mass-deleted a production database once because a C program I’d written had a use-after-free bug that corrupted a pointer used for query routing. Took us fourteen hours to recover. That was the week I started learning Rust.</p> <h2 id="the-problem-rust-solves">The Problem Rust Solves</h2> <p>Every few years, someone publishes a study on CVEs in major software projects. The numbers are always the same: roughly 70% of critical security vulnerabilities in C and C++ codebases are memory safety issues. Buffer overflows, use-after-free, double-free, null pointer dereferences. The same bugs, decade after decade.</p> </article> <article> <h1>Lesson 1: Arrays and Hashing — The Pattern Behind 30% of All Interview Questions</h1> <p>Sun, 03 Mar 2024 00:00:00 +0000</p> <p>When I was preparing for my first round of FAANG interviews, I was overwhelmed. Hundreds of LeetCode problems, dozens of patterns, no clear starting point. Then I noticed something: roughly a third of the medium-difficulty problems I encountered could be cracked with one insight — trading time for space using a hash map. Once I internalized that, arrays and hashing stopped feeling like a category and started feeling like a reflex.</p> </article> <article> <h1>Mastering Rust: The Complete Guide to Pattern Matching</h1> <p>Thu, 29 Feb 2024 18:30:00 +0000</p> <p><br> Looking to take your Rust skills to the next level? Master the art of pattern matching, one of Rust’s most versatile features! This beginner-friendly guide dives into the key concepts with clear examples, helping you:</p> <ul> <li>Understand the basics of advanced pattern matching in Rust.</li> <li>Apply these techniques to write cleaner, more efficient code.</li> <li>Avoid common pitfalls and best practices to follow.</li> </ul> <h2 id="1-basics-of-pattern-matching">1. Basics of Pattern Matching</h2> <h4 id="11-what-is-pattern-matching">1.1 What is Pattern Matching?</h4> <p>Imagine a toolbox filled with different tools for different tasks. Pattern matching works similarly, allowing you to compare your data against various “patterns” and execute the exact code you need based on the match. This brings more flexibility and security compared to traditional “if-else” statements in other languages.<br> <br> <strong>Getting Started with match:</strong></p> </article> <article> <h1>Traits: Mastering Traits in Rust — Navigating Edge Cases and Best Practices (Part 3)</h1> <p>Thu, 29 Feb 2024 18:30:00 +0000</p> <hr> <h3></h3> <p>Hello again, Rust enthusiasts! We’ve journeyed through the foundational concepts and dived into the advanced territories of Rust’s trait system in our previous posts.</p> <p>Today, we’re at the final frontier, ready to tackle the intricacies of mastering traits in Rust. This installment is all about navigating through edge cases, understanding best practices, and making the most out of Rust’s powerful trait system. So, let’s get started and wrap up our series with a deep dive into the art of mastering Rust traits.</p> </article> <article> <h1>From Novice to Master: 10 Must-Try Low-Level Programming Projects in Rust</h1> <p>Wed, 28 Feb 2024 18:30:00 +0000</p> <hr> <h3></h3> <p>Hey there! If you’ve been following along, you know we’ve been deep-diving into Rust, exploring its nooks and crannies. This time around, I’m switching gears to something more hands-on. I want to walk you through a curated list of projects that have not only sharpened my skills but promise to elevate yours from beginner to pro.</p> <h3 id="1-building-a-guessing-game-with-atwist">1. Building a Guessing Game with a Twist</h3> <p>Alright, let’s dive into something that’s simple at first glance but has layers to peel back—a guessing game, but not just any guessing game. We’re adding a twist to make it more engaging and a tad more complex, perfect for getting your feet wet with Rust’s more nuanced features.</p> </article> <article> <h1>Traits: Advanced Trait Concepts and Dynamic Dispatch in Rust (Part 2)</h1> <p>Wed, 28 Feb 2024 18:30:00 +0000</p> <hr> <h3 id="trait-objects-and-dynamicdispatch"> Trait Objects and Dynamic Dispatch</h3> <p>In Rust, polymorphism achieved through traits can take two forms: static and dynamic dispatch. Static dispatch is like knowing exactly what tool you’re going to use for a job, making it fast and efficient. Dynamic dispatch, on the other hand, is more flexible, allowing you to choose the right tool while the job is already underway.</p> <h3 id="understanding-trait-objects-and-dynkeyword">Understanding Trait Objects and dyn Keyword</h3> <p>Trait objects with the dyn keyword allow for this kind of runtime flexibility. Imagine you’re a chef with a set of kitchen tools (each representing a type). Each tool has a special function, like chopping, stirring, or scooping. In Rust, these functions are like traits, and the tools are the types that implement these traits.</p> </article> <article> <h1>Traits: Understanding Rust Traits - The Foundation (Part 1)</h1> <p>Wed, 28 Feb 2024 18:30:00 +0000</p> <hr> <p></p> <p>Welcome, fellow Rustaceans and curious minds! Today, we embark on the first installment of our series designed to explore Rust’s powerful trait system. Traits are at the heart of Rust’s type system, offering a flexible way to define shared behavior. In this post, we’ll lay the foundation, exploring what traits are, how they’re used, and why they’re so integral to Rust programming. Grab a cup of your favorite brew, and let’s dive in!</p> </article> <article> <h1>Lesson 11: Interfaces — Contracts without the paperwork</h1> <p>Sat, 24 Feb 2024 00:00:00 +0000</p> <p>When I first learned about interfaces in Go, I expected something complicated — annotations, <code>implements</code> keywords, class hierarchies. Instead, Go just asked: “does your type have the right methods?” That’s it. No paperwork. No explicit declaration. If your type does what the interface requires, it satisfies the interface automatically.</p> <p>This sounds small, but it changes how you design programs entirely.</p> <h2 id="the-basics">The Basics</h2> <p>An interface in Go is a named set of method signatures. Any type that implements those methods automatically satisfies the interface. You don’t declare that you’re satisfying it. Go figures it out at compile time.</p> </article> <article> <h1>Mastering Rust Lifetimes: The Comprehensive Guide</h1> <p>Fri, 23 Feb 2024 18:30:00 +0000</p> <h1>Mastering Rust Lifetimes: The Comprehensive Guide<br> </h1> <p>Understanding lifetimes in Rust is crucial for any Rustacean aiming to write safe and efficient code. Lifetimes are Rust’s unique approach to managing memory without a garbage collector, ensuring memory safety and eliminating data races. This guide will take you from the basics to more nuanced aspects of lifetimes, with plenty of examples to solidify your understanding.</p> <h2 id="part-1-the-foundations-of-lifetimes">Part 1: The Foundations of Lifetimes</h2> <h3 id="what-are-lifetimes">What Are Lifetimes?</h3> <p>In Rust, every reference has a lifetime, which is the scope for which that reference is valid. Lifetimes ensure that references do not outlive the data they refer to, preventing dangling references and ensuring data race freedom.</p> </article> <article> <h1>Rust Ultimate: The Ultimate Rust Cheatsheet You'll Ever Need</h1> <p>Tue, 20 Feb 2024 18:30:00 +0000</p> <p></p> <p><br> Whether you’re a seasoned developer juggling multiple programming languages or a newcomer to Rust, it’s not uncommon to hit a roadblock trying to recall specific syntax or optimize your code with Rust’s powerful features. This comprehensive Rust cheatsheet is designed to be your go-to reference, enabling you to harness Rust’s capabilities fully without getting slowed down by syntax uncertainties.</p> <h2 id="vector--linkedlist-operations">Vector & LinkedList Operations</h2> <p>Rust’s Vec<T> and LinkedList<T> are versatile for handling collections. Here’s how to use them effectively:</p> </article> <article> <h1>Lesson 10: Pointers — Addresses, not magic</h1> <p>Sat, 17 Feb 2024 00:00:00 +0000</p> <p>Pointers have a reputation for being scary. In C, they’re the source of buffer overflows, dangling references, and cryptic crashes. In Go, pointers are much tamer. There’s no pointer arithmetic, the garbage collector handles memory for you, and the rules are simpler. But pointers are still important — without them, you can’t write Go programs that mutate data through function calls, and you can’t use pointer receivers (which we covered in the last lesson).</p> </article> <article> <h1>Rust in Finance: Building a Scalable High-Frequency Trading Platform from Scratch</h1> <p>Fri, 16 Feb 2024 18:30:00 +0000</p> <p></p> <p>As I ventured deeper into the Rust ecosystem, I set my sights on a project that would not only challenge my technical acumen but also push the boundaries of software architecture — a high-frequency trading (HFT) platform. In the high-stakes world of high-frequency trading (HFT), where milliseconds can mean millions, the quest for the ultimate trading platform is relentless. With its relentless demand for speed, low latency and reliability, served as the perfect proving ground for my exploration into Rust’s capabilities and the architectural paradigms that would best harness them.</p> </article> <article> <h1>Lesson 9: Methods — Functions that belong to a type</h1> <p>Sun, 11 Feb 2024 00:00:00 +0000</p> <p>In the last lesson we defined a <code>User</code> struct. We could pass it to functions — <code>birthday(u)</code>, <code>sendEmail(u)</code>, <code>formatName(u)</code>. That works, but there’s a better way: we can attach functions directly to the <code>User</code> type. Then instead of <code>birthday(u)</code> we write <code>u.Birthday()</code>. Those are called methods.</p> <p>Methods make code more readable, more organized, and closer to how we naturally think about objects — “a user does birthday-related things” rather than “a birthday function takes a user.”</p> </article> <article> <h1>Lesson 8: Structs — Your first custom type</h1> <p>Wed, 07 Feb 2024 00:00:00 +0000</p> <p>So far we’ve been working with Go’s built-in types: strings, ints, booleans, slices, maps. Those are great, but real programs deal with real-world things — users, orders, products, messages. You need a way to group related data together and give it a meaningful name. In Go, that’s a struct.</p> <p>If you come from Python, think of a struct as a lightweight class that holds data (but with no inheritance, and methods are defined separately). If you come from JavaScript, think of it as a typed object. If you come from C, structs work almost exactly the same way.</p> </article> <article> <h1>Lesson 7: Strings, Runes, and Bytes — Strings aren't what you think</h1> <p>Fri, 02 Feb 2024 00:00:00 +0000</p> <p>Strings look simple. You write <code>"hello"</code>, you print it, done. But when I first started working with non-ASCII text in Go — names with accents, emoji, Chinese characters — things started behaving oddly. <code>len("café")</code> returned 5, not 4. Iterating with a regular index loop gave me garbled output. It took me a while to understand why, and once I did, a lot of things clicked.</p> <p>The short version: Go strings are sequences of bytes, not characters. Once you internalize that, the rest makes sense.</p> </article> <article> <h1>Lesson 6: Maps — Key-value pairs that power everything</h1> <p>Sat, 27 Jan 2024 00:00:00 +0000</p> <p>Every language has some version of the dictionary or hash map. Python calls it a <code>dict</code>, JavaScript calls it an <code>Object</code> or <code>Map</code>, Ruby calls it a <code>Hash</code>. In Go, it’s just called a map. Once you understand how Go maps work, you’ll reach for them constantly — they’re one of the most useful data structures in the language.</p> <h2 id="the-basics">The Basics</h2> <h3 id="creating-a-map">Creating a map</h3> <p>The zero value of a map is <code>nil</code>. A nil map is readable (it returns zero values) but not writable. If you try to write to a nil map, your program panics. The safe way to create a map is with <code>make</code>:</p> </article> <article> <h1>Lesson 5: Arrays and Slices — Slices are what you actually use</h1> <p>Mon, 22 Jan 2024 00:00:00 +0000</p> <p>Go has two sequence types: arrays and slices. I’ll tell you upfront — arrays are rarely used directly. They exist, they matter for understanding how things work under the hood, but in day-to-day Go programming you’ll almost always reach for a slice instead.</p> <p>Slices are Go’s workhorse collection type. They’re flexible, they grow when you need them to, and they’re used everywhere: in standard library APIs, in function parameters, in HTTP handlers. Understanding slices well will make you a much more effective Go programmer than memorizing syntax ever will.</p> </article> <article> <h1>Lesson 4: Functions — Small functions are Go's building blocks</h1> <p>Wed, 17 Jan 2024 00:00:00 +0000</p> <p>If there’s one thing experienced Go programmers agree on, it’s this: write small functions. Not tiny, cryptic one-liners, but focused functions that do one thing and are easy to test. Go’s function syntax encourages this style — it’s clean, explicit, and has one feature that’s genuinely different from most languages you’ve used before: multiple return values.</p> <p>In Python you can return a tuple. In JavaScript you can return an array. But in Go, returning two or three values is a first-class language feature with its own syntax, and it fundamentally changes how error handling works. By the end of this lesson you’ll understand Go functions well enough to start writing real, useful programs.</p> </article> <article> <h1>Lesson 3: Control Flow — if, for, and switch are all you need</h1> <p>Fri, 12 Jan 2024 00:00:00 +0000</p> <p>Every program you’ll ever write needs to make decisions and repeat actions. “If this condition is true, do that. Otherwise, do something else.” “Keep doing this until we run out of items.” These are the fundamental building blocks of logic, and Go handles them with just three constructs: <code>if</code>, <code>for</code>, and <code>switch</code>.</p> <p>That’s it. No <code>while</code>. No <code>do-while</code>. No <code>foreach</code> as a separate keyword. Go’s designers made a deliberate choice to keep the language small — fewer constructs means fewer ways to do the same thing, which means code is more consistent and easier to read across different projects and teams.</p> </article> <article> <h1>Lesson 2: Variables and Types — Go is typed, and that's a good thing</h1> <p>Mon, 08 Jan 2024 00:00:00 +0000</p> <p>If you’re coming from Python or JavaScript, Go’s type system might feel like extra work at first. Why should you have to tell the compiler that a variable holds a number? Can’t it just figure it out?</p> <p>Here’s the thing — it usually can. Go has type inference, so you rarely have to write out types explicitly. But when types <em>are</em> written out, every person reading your code knows exactly what kind of data they’re dealing with. There’s no guessing, no surprises at runtime because a string snuck in where you expected a number. Go catches those mistakes at compile time, before your code ever runs.</p> </article> <article> <h1>Lesson 1: Your First Go Program — Hello World is just the beginning</h1> <p>Wed, 03 Jan 2024 00:00:00 +0000</p> <p>I remember the first time I ran a Go program. The compiler yelled at me for an unused import, and I thought, “Okay, this language has opinions.” That’s not a bad thing. Go’s strictness is part of what makes it so readable and maintainable. Once you understand <em>why</em> Go works the way it does, it starts to feel less like friction and more like clarity.</p> <p>In this lesson you’re going to write your first Go program, understand every single line of it, and learn the basic tools you’ll use every day. By the end, “Hello, World!” won’t feel like a throwaway demo — it’ll feel like a foundation.</p> </article> <article> <p>Mon, 01 Jan 0001 00:00:00 +0000</p> <h1 id="atharva-pandey-blockchain--backend-developer-">Atharva Pandey: Blockchain & Backend Developer 👋</h1> <p>I’m Atharva Pandey, a dynamic technology leader specializing in <strong>blockchain</strong> and <strong>backend development</strong>. With a proven track record in leading diverse teams and projects, I’ve been instrumental in delivering innovative solutions in the blockchain space, leveraging my skills as a Generalist and Polyglot.</p> <h2 id="-professional-journey">🚀 Professional Journey</h2> <p>As the <strong>CTO of Adguin</strong>, I spearheaded the creation of an <strong>NFT-based advertising platform</strong>, designing scalable, robust solutions from scratch. My career includes impactful roles such as Fractional CTO at Firbond and Senior Software Engineer at Crew3, where I honed my expertise in using technology to drive industry transformation.</p> </article> </main></body></html>