Rust Tutorial on

Lesson 10: When Not to Use Rust — Honest trade-offs

Wed, 05 Nov 2025 11:46:00 +0000

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.

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.

Lesson 9: War Stories — Lessons from real Rust deployments

Sun, 02 Nov 2025 15:08:00 +0000

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.

These are real stories. Some names and details are changed, but the bugs and the lessons are exactly as they happened.

Lesson 8: Migrating Services from Go/Python/Java to Rust — When and how

Thu, 30 Oct 2025 09:33:00 +0000

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.

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.

Lesson 7: Feature Flags at the Type Level — Compile-time feature control

Tue, 28 Oct 2025 13:19:00 +0000

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.

In Rust, we had another option. We could decide at compile time 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.

Lesson 6: API Versioning and Backwards Compatibility — Don't break your users

Sun, 26 Oct 2025 10:55:00 +0000

I once shipped a “minor” API change on a Friday. Renamed a JSON field from user_name to username. 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.

That was the last time I treated backwards compatibility as optional.

Lesson 5: Multi-Crate Workspace Architecture — Scaling your codebase

Thu, 23 Oct 2025 16:42:00 +0000

Our compile times hit 8 minutes. Not from scratch — incremental. 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.

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 Cargo.toml with 47 dependencies. Touch anything and the whole thing recompiles.

Lesson 10: Interpreter Pattern — DSLs and parsing

Wed, 22 Oct 2025 12:00:00 +0000

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.

Lesson 4: CQRS and Event Sourcing — Separating reads from writes

Tue, 21 Oct 2025 08:27:00 +0000

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.

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.

Lesson 9: Entity Component System — Data-oriented design

Sun, 19 Oct 2025 15:30:00 +0000

I spent years thinking about game objects the OOP way. A Player extends Character extends Entity. A Goblin extends Enemy extends Character extends Entity. Then someone asks “what if a goblin can be mind-controlled and act like a player?” and your inheritance hierarchy collapses.

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.

Lesson 3: Hexagonal Architecture in Rust — Ports, adapters, and boundaries

Sun, 19 Oct 2025 11:05:00 +0000

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.

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.

Lesson 2: Domain Modeling with Rust's Type System — Making impossible states impossible

Fri, 17 Oct 2025 14:38:00 +0000

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 user_id where an order_id was expected. Both were String. Both were UUIDs. The compiler had no way to tell them apart. The function signature said fn cancel_order(order_id: String, user_id: String), and someone called it with the arguments flipped.

This is the kind of bug that makes you rethink everything. Not because it’s complex — because it’s stupid. And stupid bugs that slip through a strong type system mean the type system wasn’t being used right.

Lesson 8: Middleware / Chain of Responsibility — Tower-style

Thu, 16 Oct 2025 07:15:00 +0000

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.

The Chain of Responsibility pattern from the GoF book is basically the same thing. The difference is branding.

What makes this pattern interesting in Rust is tower — the crate that defines how middleware works across the entire Rust async ecosystem. Axum, Tonic, Hyper — they all use Tower’s Service trait. Understanding it unlocks the middleware patterns in all of these frameworks.

Lesson 1: Structuring a Large Rust Application — Beyond hello world

Wed, 15 Oct 2025 09:14:00 +0000

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 src/ directory, and realized I couldn’t confidently answer. We had 40,000 lines of Rust spread across files with names like utils.rs, helpers.rs, types.rs, and the ever-popular misc.rs. Everything compiled. Nothing made sense.

Most Rust tutorials stop at “put your code in main.rs and maybe lib.rs.” 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.

Lesson 7: Repository Pattern — Abstracting storage

Mon, 13 Oct 2025 13:45:00 +0000

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.

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.

Lesson 6: Factory Patterns — When constructors aren't enough

Sat, 11 Oct 2025 10:00:00 +0000

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.

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?

Lesson 5: Decorator Pattern — Wrapping with trait composition

Thu, 09 Oct 2025 16:30:00 +0000

I remember the moment Decorator clicked for me. I was reading the source for Java’s I/O library — BufferedInputStream wrapping FileInputStream wrapping InputStream. 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.

The good news? Rust’s version is often better than the OOP original, because composition is the default and the compiler enforces the contracts.

Lesson 4: Command Pattern — Closures as commands

Tue, 07 Oct 2025 09:20:00 +0000

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 Command interface with an execute() 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.

In Rust, closures are 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.

Lesson 3: Observer Pattern — Channels and callbacks in Rust

Sun, 05 Oct 2025 11:45:00 +0000

The Observer pattern is where Rust’s ownership model gets really 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.

Lesson 2: Strategy Pattern — Trait objects and generics

Fri, 03 Oct 2025 14:15:00 +0000

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 dyn, Box, 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.

Lesson 8: Runtime Comparison — Tokio vs async-std vs smol vs glommio

Thu, 02 Oct 2025 16:55:31 +0000

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.

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.

Lesson 1: Builder Pattern — Typestate builders and compile-time validation

Wed, 01 Oct 2025 08:30:00 +0000

I once spent three days debugging a production outage caused by a builder that silently accepted a missing host field and defaulted to localhost. 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.

Rust’s type system lets you make that entire category of bug impossible. Not at runtime. Not with validation methods. At compile time.

Lesson 7: Designing a Custom Async Runtime — When Tokio isn't enough

Tue, 30 Sep 2025 11:20:06 +0000

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.

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.

Lesson 6: Work-Stealing Schedulers — Balancing load across cores

Sat, 27 Sep 2025 13:45:50 +0000

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.

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.

Lesson 5: The Reactor Pattern — How Tokio actually works

Wed, 24 Sep 2025 09:27:13 +0000

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.

This lesson is about that architecture. Not Tokio’s API — you already know how to use tokio::spawn and TcpStream. This is about what happens underneath when you call those functions. The reactor pattern, the I/O driver, the timer wheel, and how they all feed into the executor.

Lesson 10: Dependent Type Tricks — Encoding constraints in types

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

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

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

Lesson 4: epoll/kqueue — Platform event loops

Sun, 21 Sep 2025 17:08:45 +0000

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

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

Lesson 9: Proof Witnesses — Types as proofs

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

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

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

Lesson 3: io_uring — Zero-copy async I/O on Linux

Fri, 19 Sep 2025 10:33:08 +0000

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

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

Lesson 2: Building a Minimal Executor — Your own async runtime

Wed, 17 Sep 2025 14:12:37 +0000

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

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

Lesson 8: Sealed Traits — Closing extension points

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

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

Lesson 1: Future Internals — Poll, Waker, Context

Mon, 15 Sep 2025 08:45:22 +0000

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

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

Lesson 7: Type-Level Programming — Computing with types

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

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

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

Lesson 6: Variance — Covariance, contravariance, invariance

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

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

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

Lesson 5: Existential Types — impl Trait in depth

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

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

Let me show you.

Two Positions, Two Meanings

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

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

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

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

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

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

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

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

Lesson 3: Session Types — Protocol safety at compile time

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

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

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

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

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

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

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

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

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

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

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

Lesson 8: ML Data Pipelines — polars and processing at speed

Sat, 30 Aug 2025 14:15:00 +0000

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.

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.

Lesson 7: On-Device Inference — ONNX Runtime and candle

Tue, 26 Aug 2025 07:49:00 +0000

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.”

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.

Lesson 6: Building MCP Servers in Rust — Model Context Protocol

Fri, 22 Aug 2025 10:23:00 +0000

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.

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.

Lesson 5: Agent Architectures in Rust — ReAct, planning, and loops

Wed, 20 Aug 2025 13:08:00 +0000

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.”

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.

Lesson 8: Reproducible Builds — Same source, same binary

Mon, 18 Aug 2025 15:25:00 +0000

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 cargo build --release, 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.

Why Reproducible Builds Matter

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.

Lesson 4: Embeddings and Vector Search — Semantic search in Rust

Mon, 18 Aug 2025 08:55:00 +0000

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.

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.

Lesson 3: Tool Calling / Function Calling Patterns — Agents need tools

Sat, 16 Aug 2025 16:42:00 +0000

Here’s something that took me embarrassingly long to internalize: LLMs don’t do things. They generate text that describes 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.

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.

Lesson 7: Linking Strategies — Static, dynamic, LTO

Fri, 15 Aug 2025 10:40:00 +0000

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.

What Linking Actually Is

When you write cargo build, the compiler doesn’t produce a binary directly. It produces object files — chunks of machine code for each compilation unit. The linker takes all those object files, plus any libraries you depend on, and stitches them together into a single executable.

Lesson 2: Streaming LLM Responses — SSE and WebSockets

Thu, 14 Aug 2025 11:37:00 +0000

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.

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.

Lesson 6: Monorepo Management with Workspaces — Scaling Rust projects

Tue, 12 Aug 2025 13:10:00 +0000

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 cargo build was doing weird things because three of them depended on different versions of serde. That’s when we sat down and properly set up a workspace.

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.

Lesson 1: Building LLM API Clients in Rust — Type-safe AI calls

Tue, 12 Aug 2025 09:14:00 +0000

Last month I watched a coworker’s Python script silently swallow a malformed response from the OpenAI API. The choices field came back empty, the code plowed ahead with choices[0], and the whole pipeline crashed at 2 AM. Nobody got paged because the error handler was also broken. Classic.

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.

Lesson 5: Code Generation — proc macros, build.rs, xtask

Sun, 10 Aug 2025 08:55:00 +0000

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.

Lesson 12: Production Systems Software — Databases, runtimes, proxies

Fri, 08 Aug 2025 09:33:27 +0000

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 — no_std 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.

Lesson 4: Custom Lints with clippy and dylint — Your team's rules

Thu, 07 Aug 2025 16:20:00 +0000

We had this rule on my old team: never use .unwrap() 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 .unwrap() on a sqlx::Result 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.

Lesson 3: Conditional Compilation — cfg, features, target

Tue, 05 Aug 2025 11:45:00 +0000

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 cfg 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.

Lesson 11: Building a Minimal Hypervisor — Virtualization in Rust

Mon, 04 Aug 2025 15:42:18 +0000

The first time I watched a virtual machine boot — not using VirtualBox, but running inside a hypervisor I’d written — 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 fake machine that thought it was running on bare metal.

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.

Lesson 2: build.rs — Code generation at compile time

Sun, 03 Aug 2025 14:30:00 +0000

The first time I needed build.rs, 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 const 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.

Lesson 10: Writing a Bootloader — The first code that runs

Fri, 01 Aug 2025 22:10:44 +0000

There’s something almost spiritual about writing a bootloader. Your code is the first thing that runs 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.

I spent a weekend writing one. By Sunday night, I had four characters on screen — BOOT — rendered by writing directly to VGA memory. And it felt like I’d conquered the world.

Lesson 1: Cargo Deep Dive — Workspaces, features, profiles

Fri, 01 Aug 2025 09:15:00 +0000

I’d been writing Rust for about a year before I realized I was only using maybe 20% of what Cargo actually offers. cargo build, cargo run, cargo test — 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.

Cargo Is Not Just a Build Tool

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.

Lesson 9: Interrupt Handlers and Real-Time Constraints — When timing matters

Wed, 30 Jul 2025 06:55:22 +0000

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.

Lesson 8: Designing Custom Allocators — Beyond the global allocator

Sun, 27 Jul 2025 13:19:56 +0000

Here’s a dirty secret of systems programming: malloc 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.

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%.

Lesson 7: Implementing Network Protocols — TCP from scratch

Thu, 24 Jul 2025 10:31:48 +0000

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.

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.

Lesson 6: Building a File System — From blocks to files

Tue, 22 Jul 2025 16:08:32 +0000

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

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

Lesson 5: OS Concepts in Rust — Processes, threads, signals

Sat, 19 Jul 2025 07:45:19 +0000

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

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

Lesson 8: The Component Model — Composable WASM modules

Fri, 18 Jul 2025 10:41:09 +0000

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

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

Lesson 4: Writing Linux Kernel Modules in Rust — Rust in the kernel

Thu, 17 Jul 2025 11:23:45 +0000

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

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

Lesson 7: WASI — WebAssembly beyond the browser

Tue, 15 Jul 2025 19:22:41 +0000

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

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

Lesson 3: Memory-Mapped I/O — Talking to hardware

Mon, 14 Jul 2025 19:52:07 +0000

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

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

Lesson 6: Multi-Threaded WASM — SharedArrayBuffer and atomics

Sun, 13 Jul 2025 07:55:18 +0000

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

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

Lesson 2: Embedded Rust — Microcontrollers and bare metal

Sat, 12 Jul 2025 14:37:51 +0000

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.

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 structure hardware access so mistakes become harder to make.

Lesson 5: WASM Performance — When it beats JavaScript

Thu, 10 Jul 2025 16:08:51 +0000

“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 can 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.

I ran benchmarks for months to figure out where the real boundaries are. Let me show you the data.

Lesson 1: no_std — Rust without the standard library

Thu, 10 Jul 2025 08:14:33 +0000

The first time I tried to compile a Rust program with #![no_std], I felt like someone had pulled the floor out from under me. No println!. No String. No Vec. No HashMap. Half the stuff I relied on daily — just gone.

And that’s exactly the point.

Why Would Anyone Do This?

Here’s the thing most Rust tutorials won’t tell you up front: the standard library is enormous. 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:

Lesson 4: Leptos, Yew, Dioxus — Full-stack Rust

Mon, 07 Jul 2025 09:17:33 +0000

After building that todo list with raw web-sys in Lesson 3, I think we can all agree: manually managing DOM nodes, closures wrapped in Rc<RefCell<Option<Closure<dyn FnMut()>>>>, 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.

I’ve built side projects with all three. Let me tell you what actually matters when choosing between them.

Lesson 3: Manipulating the DOM from Rust — Web without JavaScript

Sat, 05 Jul 2025 11:33:47 +0000

There’s something deeply satisfying about writing document.create_element("div") in Rust and watching it actually work in a browser. It’s also, if I’m being honest, kind of painful — because web-sys wraps every single Web API call in Result types, and you end up with .unwrap() 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.

Lesson 10: Soundness — The ultimate safety guarantee

Fri, 04 Jul 2025 16:50:00 +0000

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 unsafe in the caller’s code. The bug was in my unsafe 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 always in the library.

Lesson 2: wasm-bindgen — Bridging Rust and JavaScript

Thu, 03 Jul 2025 14:12:05 +0000

The first time I looked at what #[wasm_bindgen] 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 model, because when things go wrong (and they will), the model is what helps you debug.

Lesson 9: napi-rs — Rust extensions for Node.js

Tue, 01 Jul 2025 13:26:00 +0000

We had a Node.js microservice that validated JWTs. Under load, the jsonwebtoken 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.

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.

Lesson 1: Rust to WebAssembly — Why and how

Tue, 01 Jul 2025 08:45:22 +0000

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.

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.

Lesson 8: PyO3 — Rust extensions for Python

Sat, 28 Jun 2025 08:14:00 +0000

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.

Lesson 7: Exposing Rust to C — cdylib and cbindgen

Wed, 25 Jun 2025 15:40:00 +0000

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.

Lesson 6: FFI — Calling C from Rust

Mon, 23 Jun 2025 11:55:00 +0000

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 CString while SQLite was still reading from the pointer. That experience taught me more about unsafe Rust than any tutorial ever could.

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.

Lesson 5: Building Safe Abstractions Over Unsafe Code — The encapsulation pattern

Fri, 20 Jun 2025 09:22:00 +0000

The standard library’s Vec<T> contains over 50 unsafe blocks. HashMap has even more. Yet you use both every day without thinking about safety — because their public APIs are entirely safe. The unsafe is invisible, encapsulated behind type system boundaries that make misuse impossible.

This is the most important pattern in Rust: unsafe internals, safe surface. Master it, and you can build anything.

The Core Principle

An unsafe 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 users of your code can’t break the invariants no matter what they do.

Lesson 4: transmute — Type punning and its dangers

Wed, 18 Jun 2025 17:08:00 +0000

I once watched a senior engineer transmute a Vec<u8> into a Vec<u32> 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 u8 vec, and u32 needs 4-byte alignment. On x86 you pay a performance penalty; on ARM you get a bus error.

transmute 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.

Lesson 8: Monolith-First — Modular monoliths in Rust

Tue, 17 Jun 2025 13:19:00 +0000

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 designed to be split later.

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.

Lesson 3: Dereferencing Raw Pointers Safely — The patterns that work

Mon, 16 Jun 2025 10:45:00 +0000

A colleague once showed me a bug that took them three days to find. Their unsafe 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.

Dereferencing raw pointers is the most common unsafe operation you’ll encounter, and getting it right means following specific patterns. Not guidelines — patterns. Repeatable, auditable approaches that make your unsafe code reviewable.

Lesson 2: Raw Pointers — const T, mut T and when you need them

Sat, 14 Jun 2025 14:17:00 +0000

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.

References vs Raw Pointers

Rust references (&T and &mut T) come with guarantees enforced by the compiler:

Lesson 7: Testing Microservices — Contract tests and integration

Sat, 14 Jun 2025 07:33:00 +0000

I deployed a change to the order service that renamed a field from total_amount to total_cents. Made perfect sense — cents avoid floating-point nonsense. All unit tests passed. Integration tests passed. Staging looked fine.

Production broke instantly. The payment service was still expecting total_amount. It deserialized the response, got None for the amount, and started processing $0 charges. We caught it in four minutes, but four minutes of free orders adds up.

Lesson 1: What unsafe Actually Means — The contract you're signing

Thu, 12 Jun 2025 08:32:00 +0000

I spent my first six months writing Rust thinking unsafe 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 unsafe really means, everything clicked.

Let’s clear this up properly.

unsafe Is Not What You Think

Here’s the biggest misconception in the Rust ecosystem: unsafe does not mean “this code is broken” or “this code does bad things.” It means “I, the programmer, am upholding invariants that the compiler cannot verify.”

Lesson 6: Distributed Tracing Across Services — Following requests

Wed, 11 Jun 2025 10:45:00 +0000

“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.

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.

Lesson 5: Service Mesh Integration — Istio, Linkerd, and Rust

Mon, 09 Jun 2025 16:21:00 +0000

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?

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.

Lesson 4: Saga Pattern — Distributed transactions without 2PC

Sat, 07 Jun 2025 08:48:00 +0000

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.

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.

Lesson 3: Event-Driven Architecture in Rust — Decoupled systems

Thu, 05 Jun 2025 11:02:00 +0000

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.

Lesson 10: Distributed System Patterns — Consensus, CRDTs, and consistency

Wed, 04 Jun 2025 11:08:00 +0000

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.

Lesson 2: gRPC Microservices with tonic — Production-grade RPC

Tue, 03 Jun 2025 14:37:00 +0000

The first time I used gRPC in production was on a Go project. The experience was fine — protoc generated stubs, you implemented an interface, done. Then I tried tonic in Rust, and I realized what gRPC was supposed 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.

Lesson 9: Message Queues — NATS, Kafka, RabbitMQ from Rust

Sun, 01 Jun 2025 15:25:00 +0000

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.

Lesson 1: Service Boundaries and API Contracts — Where to draw the lines

Sun, 01 Jun 2025 09:14:00 +0000

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.

Lesson 8: Circuit Breakers in Rust — Failing fast

Thu, 29 May 2025 07:35:00 +0000

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.

Lesson 7: Retry Strategies and Exponential Backoff — Resilient clients

Mon, 26 May 2025 10:40:00 +0000

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.

Lesson 6: TLS — rustls and native TLS

Fri, 23 May 2025 19:10:00 +0000

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.

Lesson 5: DNS Resolution and Custom Resolvers — Understanding name resolution

Wed, 21 May 2025 13:55:00 +0000

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 dig on my laptop showed the correct answer, but the services inside the cluster were seeing stale records.

Lesson 8: Security Fuzzing — Finding vulnerabilities before attackers do

Sun, 18 May 2025 13:29:00 +0000

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.

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.

Lesson 4: WebSocket Servers and Clients — Real-time communication

Sun, 18 May 2025 08:20:00 +0000

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.

HTTP vs WebSockets — When Do You Need Them?

HTTP is request-response. Client asks, server answers. Great for most things. But some use cases fundamentally don’t fit that model:

Lesson 3: gRPC with tonic — High-performance RPC

Fri, 16 May 2025 11:30:00 +0000

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.

Lesson 7: Sandboxing and Privilege Dropping — Least privilege

Thu, 15 May 2025 07:41:00 +0000

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.

Lesson 2: HTTP Clients — reqwest and hyper

Wed, 14 May 2025 16:45:00 +0000

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.

Lesson 6: Supply Chain Security — Lockfiles, vendoring, and trust

Mon, 12 May 2025 10:08:00 +0000

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.

I spent a week last year hardening our build pipeline after we realized that a cargo build 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.

Lesson 1: Building a TCP Server from Scratch — Raw sockets

Mon, 12 May 2025 09:14:00 +0000

Last month I was debugging a flaky microservice at work and realized I couldn’t explain what was actually happening between bind() 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.

Lesson 5: Dependency Auditing — cargo-audit and cargo-deny

Fri, 09 May 2025 14:55:00 +0000

You know what keeps me up at night? Not my own code — I can review that. It’s the 200+ transitive dependencies in my Cargo.lock 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.

This isn’t theoretical. In 2024, the xz 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 unsafe code in popular crates, logic bugs in crypto implementations.

Lesson 8: Release Profiles and Build Optimization — Shipping fast binaries

Thu, 08 May 2025 13:50:00 +0000

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 Cargo.toml settings.

Most Rust developers know about cargo build --release. Fewer know that --release 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.

Lesson 4: Secret Management — zeroize and secure memory

Wed, 07 May 2025 08:23:00 +0000

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 String, and that String stayed in memory for the entire process lifetime. When it crashed, the secret got written to disk in the core dump.

Lesson 3: Cryptography — ring, RustCrypto, and sodiumoxide

Mon, 05 May 2025 11:47:00 +0000

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.

But you still need to use 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.

Lesson 7: Configuration — Environment, files, feature flags

Mon, 05 May 2025 10:15:00 +0000

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 const. 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.

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.

Lesson 2: Input Validation and Sanitization — Trust nothing

Sat, 03 May 2025 16:12:00 +0000

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 — ../../etc/passwd would work just fine.

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.

Lesson 6: Graceful Shutdown — Draining connections cleanly

Fri, 02 May 2025 19:45:00 +0000

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.

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 then exit. Get this right and you get zero-downtime deployments. Get it wrong and you get data loss.

Lesson 1: Memory Safety — What Rust gives you for free

Thu, 01 May 2025 09:34:00 +0000

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.

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.

Lesson 5: Health Checks and Readiness Probes — Production liveness

Wed, 30 Apr 2025 14:05:00 +0000

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 /health endpoint — which didn’t touch the database — happily reported everything was fine.

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.

Lesson 4: Observability — tracing, metrics, OpenTelemetry

Sun, 27 Apr 2025 08:22:00 +0000

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 println! statements, deploying them one at a time, and watching CloudWatch. It was miserable.

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.

Lesson 3: CI/CD for Rust — GitHub Actions, caching, cargo-nextest

Thu, 24 Apr 2025 11:30:00 +0000

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.

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.

Lesson 10: Using unsafe to Escape the Borrow Checker — The wrong reason

Thu, 24 Apr 2025 09:30:00 +0000

I found this in a production codebase:

fn get_or_insert(&mut self, key: &str) -> &mut Value {
 if !self.map.contains_key(key) {
 self.map.insert(key.to_string(), Value::default());
 }
 // "The borrow checker is being stupid, we know the key exists"
 unsafe { &mut *(self.map.get_mut(key).unwrap() as *mut Value) }
}

The comment says it all. The developer hit a borrow checker error — a legitimate one about borrowing self.map 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 will optimize based on that assumption. When it does, your program does something you didn’t write.

Lesson 2: Static Linking with musl — Single binary deploys

Tue, 22 Apr 2025 16:40:00 +0000

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 /usr/lib, 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.

Lesson 9: Macro Abuse — When a function would do

Mon, 21 Apr 2025 17:08:00 +0000

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 make_handler! 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 macro_rules! with five recursion levels, three tt 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.

Lesson 1: Docker for Rust — Multi-stage builds, minimal images

Sun, 20 Apr 2025 09:15:00 +0000

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 rust:latest as my base, ran cargo build --release 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.

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.”

Lesson 8: Premature Optimization — Profile before you optimize

Sat, 19 Apr 2025 13:42:00 +0000

A teammate once spent three days replacing every String 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.

Lesson 7: Arc> as Default — Reach for channels first

Wed, 16 Apr 2025 20:15:00 +0000

There’s a specific moment in every Rust developer’s journey where they discover Arc<Mutex<T>> 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 Arc<Mutex<HashMap<String, CachedItem>>>. 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.

Lesson 6: Trait Bloat — Interface segregation in Rust

Tue, 15 Apr 2025 09:55:00 +0000

I worked on a project that had a Storage 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 unimplemented!(). 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.

Lesson 5: Over-Genericizing — Not everything needs

Sun, 13 Apr 2025 11:28:00 +0000

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:

let client: HttpClient<
 TcpTransport<TlsConfig>,
 JsonSerializer<PrettyPrint>,
 JsonDeserializer<StrictMode>,
 AppError,
 ExponentialBackoff<SystemClock>,
 FixedTimeout,
 SlogLogger<JsonFormat>,
> = HttpClient::new(/* ... */);

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.

Lesson 12: Zero-Copy Parsing — bytes, nom, winnow

Sat, 12 Apr 2025 11:30:00 +0000

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 String — peaked at 6GB memory usage and fell over. The data was being duplicated everywhere: once in the read buffer, once in each split String, once in the output struct. Three copies of every byte.

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.

Lesson 4: God Structs — When types do too much

Fri, 11 Apr 2025 16:10:00 +0000

I once opened a file called app.rs 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 &self 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.

Lesson 3: Stringly Typed APIs — Use enums, not strings

Wed, 09 Apr 2025 08:47:00 +0000

I inherited a Rust codebase once where the entire state machine was driven by string comparisons. The order status could be "pending", "processing", "shipped", "delivered", or "cancelled". Except sometimes it was "Pending" with a capital P. And there was one code path that set it to "canceled" — one L, American spelling. And another that used "CANCELLED". 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 if status == "cancelled" checks scattered across thirty files.

Lesson 2: unwrap() in Production — Time bombs waiting to explode

Mon, 07 Apr 2025 14:35:00 +0000

A service I was responsible for went down at 2 AM on a Saturday because of a single .unwrap() 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 .unwrap() detonated like a landmine — thread 'main' panicked at 'called Option::unwrap() on a None value'. Down. Dead. Pager screaming.

Lesson 11: Binary Size Reduction — Smaller deployments

Mon, 07 Apr 2025 13:17:00 +0000

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.

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.

Lesson 1: .clone() Everywhere — Hiding ownership problems

Sat, 05 Apr 2025 10:22:00 +0000

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 grep -c '\.clone()' src/ 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 .clone() call until the compiler stopped yelling.

Lesson 10: Compile Time Optimization — Strategies that actually work

Thu, 03 Apr 2025 08:55:00 +0000

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.

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.

Lesson 9: Inlining — #[inline] and LTO

Mon, 31 Mar 2025 19:05:00 +0000

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.

Lesson 8: Cache-Friendly Data Structures — Data-oriented design

Sat, 29 Mar 2025 07:40:00 +0000

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.

Lesson 7: Choosing the Right Collection — It's not always Vec

Thu, 27 Mar 2025 15:22:00 +0000

A friend asked me to review their service that was doing “thousands of lookups per second” against a Vec of about 50,000 entries. Linear scan every time. They’d chosen Vec because “it’s the default” and hadn’t thought about it further. Swapping to a HashMap took the lookup from 12µs to 40ns. Three hundred times faster. From a one-line change.

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.

Lesson 6: String Performance — SmartString, CompactStr, and when to care

Tue, 25 Mar 2025 11:50:00 +0000

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 String 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.

Switching to CompactStr cut memory usage by 60% and index-building time by 40%. Strings matter more than you think.

Lesson 5: Iterators vs Loops — Performance characteristics

Sun, 23 Mar 2025 09:12:00 +0000

When I first started writing Rust, I wrote everything as for 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?

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.

Lesson 10: How rustc Works — From source code to binary

Sat, 22 Mar 2025 11:30:00 +0000

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.

The Big Picture

When you run cargo build, your source code goes through six major stages before becoming a binary:

Lesson 4: Reducing Allocations — Stack, arena, SmallVec

Fri, 21 Mar 2025 16:30:00 +0000

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.

The fix took half a day and cut allocations to about 200 per request. Here’s everything I know about reducing allocations in Rust.

Lesson 3: Profiling — perf, flamegraph, samply

Wed, 19 Mar 2025 10:45:00 +0000

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 Drop implementations, deallocating thousands of small strings that were created and immediately discarded. The JSON parsing was 4% of runtime.

Profiling would’ve found that in five minutes. That’s why this lesson exists.

Lesson 9: Miri — Your safety net for unsafe Rust

Wed, 19 Mar 2025 08:45:00 +0000

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.

Lesson 2: Benchmarking with criterion and divan — Statistically rigorous benchmarks

Mon, 17 Mar 2025 14:18:00 +0000

Last year I reviewed a PR where someone claimed their new serialization code was “2x faster.” Their benchmark? std::time::Instant::now() called once before and once after. Single run. No warmup. No statistical analysis. The “2x speedup” was thermal throttling on the first run.

Benchmarking is harder than it looks. Let’s do it properly.

Why Naive Benchmarks Lie

Before we get into the tools, let me show you all the ways a naive benchmark can mislead you:

Lesson 8: Custom Allocators — GlobalAlloc, arena allocation, and beyond

Sun, 16 Mar 2025 13:10:00 +0000

I was building a JSON parser that processed millions of small documents per second. Profiling showed that 40% of the time was spent in malloc and free — 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.

How Rust Allocates Memory

When you write Box::new(42) or Vec::with_capacity(100), Rust asks the global allocator for memory. By default, this is the system allocator — malloc/free on Unix, HeapAlloc/HeapFree 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.

Lesson 1: Performance Philosophy — Measure, don't guess

Sat, 15 Mar 2025 08:32:00 +0000

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 HashMap 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.

Three days. Zero meaningful impact. That’s the lesson I want to start this entire course with.

Lesson 7: Drop Order — Deterministic destruction and why it matters

Thu, 13 Mar 2025 07:20:00 +0000

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.

The Drop Trait

In Rust, cleanup logic is implemented through the Drop trait. When a value goes out of scope, the compiler calls drop() on it automatically. This is RAII — Resource Acquisition Is Initialization — borrowed from C++ but made more reliable by the ownership system.

Lesson 6: repr(C), repr(transparent), repr(packed) — Taking control of memory layout

Tue, 11 Mar 2025 09:55:00 +0000

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 #[repr(C)].

Default Rust Layout: repr(Rust)

By default, Rust structs use repr(Rust) — 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:

Lesson 5: Fat Pointers — &dyn Trait, &[T], and &str under the hood

Sun, 09 Mar 2025 16:40:00 +0000

I remember being confused why &str 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.

Thin Pointers vs Fat Pointers

Most references in Rust are “thin” — a single machine word pointing to the data:

Lesson 4: vtables — How dyn Trait actually works under the hood

Fri, 07 Mar 2025 11:15:00 +0000

I was profiling a parser once and found that a hot path using dyn Iterator 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 dyn really costs. Let’s open the hood.

Static vs Dynamic Dispatch

Rust gives you two ways to call methods on trait objects: static dispatch (generics) and dynamic dispatch (dyn Trait).

Lesson 3: Box — Heap allocation by choice

Wed, 05 Mar 2025 08:30:00 +0000

When I first started writing Rust, I used Box everywhere. Came from a Java background where everything lives on the heap, and wrapping things in Box 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 Box, nothing else will do.

What Box Actually Is

Box<T> is the simplest smart pointer in Rust. It allocates a value of type T on the heap and gives you ownership of that allocation through a pointer on the stack. When the Box goes out of scope, it frees the heap memory. That’s it. No reference counting, no garbage collection, no magic.

Lesson 12: Macro Anti-Patterns — When not to macro

Tue, 04 Mar 2025 12:50:00 +0000

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 println! 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 not to use macros than any tutorial ever could.

Lesson 2: Stack vs Heap — Where your data actually lives

Mon, 03 Mar 2025 14:45:00 +0000

A colleague once asked me why their Rust program was ten times slower than expected. They were allocating a Vec<u8> inside a tight loop — millions of heap allocations per second. Moved the vec outside the loop, pre-allocated with with_capacity, 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.

Two Memory Regions, Two Personalities

Your program has (at minimum) two regions of memory to work with: the stack and the heap. 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.

Lesson 11: Real-World Macro Patterns — serde, clap, sqlx under the hood

Sat, 01 Mar 2025 15:40:00 +0000

I used #[derive(Serialize)] for two years before I actually looked at what it generates. When I finally ran cargo expand 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.

Lesson 1: Memory Layout — Size, alignment, and the padding you never asked for

Sat, 01 Mar 2025 10:22:00 +0000

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.

Why Layout Matters

Every type in Rust has two fundamental properties: size and alignment. 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.

Lesson 10: syn and quote — Parsing and generating tokens

Thu, 27 Feb 2025 10:20:00 +0000

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

Lesson 9: Function-Like Proc Macros — sql!() and friends

Mon, 24 Feb 2025 18:30:00 +0000

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

Lesson 8: Attribute Macros — #[my_attr] in practice

Sat, 22 Feb 2025 07:15:00 +0000

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

Lesson 7: Derive Macros — Custom #[derive()]

Wed, 19 Feb 2025 13:55:00 +0000

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.

Lesson 6: Procedural Macros — The three kinds

Mon, 17 Feb 2025 09:40:00 +0000

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

What Procedural Macros Actually Are

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

Lesson 5: Debugging Macros — cargo-expand and trace_macros

Fri, 14 Feb 2025 11:05:00 +0000

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.

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 see the generated code, and then reason backwards from there to figure out where the pattern matching went wrong.

Lesson 20: Production Async Architecture — Connection pools, retries, circuit breakers

Wed, 12 Feb 2025 17:09:33 +0000

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.

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.

Lesson 4: Macro Hygiene — Scoping and naming pitfalls

Wed, 12 Feb 2025 16:10:00 +0000

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 result — which happened to shadow a result 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.

Lesson 19: Testing Async Code — Mocking time and I/O

Mon, 10 Feb 2025 11:28:56 +0000

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.

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.

Lesson 3: Macro Pattern Matching — Repetition, fragments, and captures

Mon, 10 Feb 2025 08:30:00 +0000

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 tt 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.

Repetition Operators Deep Dive

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.

Lesson 18: Tracing Async Code — Context propagation across .await

Sat, 08 Feb 2025 15:43:29 +0000

Debugging async code with println! 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.

The tracing crate solves this. It gives you structured, contextual logging that follows your request across tasks, .await points, and even service boundaries. I switched from log to tracing three years ago and haven’t looked back.

Lesson 2: Declarative Macros — macro_rules! from zero

Fri, 07 Feb 2025 14:45:00 +0000

The first macro I ever wrote was a disaster. I wanted a shorthand for creating HashMaps — something like map!{ "a" => 1, "b" => 2 }. 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.

Lesson 17: Pin in Async Context — Why futures must be pinned

Thu, 06 Feb 2025 08:27:44 +0000

I’ve been hand-waving around Pin for 16 lessons. Every time we saw Pin<&mut Self> in a poll 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.

The good news: the mental model is simpler than it looks. The bad news: the syntax is still ugly. Let’s deal with both.

The Problem Pin Solves

When the compiler turns your async fn into a state machine, it needs to store local variables across .await points. Sometimes those variables reference each other:

Lesson 1: Why Macros — When functions aren't enough

Wed, 05 Feb 2025 10:22:00 +0000

I spent three hours once writing nearly identical impl blocks for sixteen different numeric types. Copy, paste, change i32 to i64, change i64 to u32, repeat. Halfway through I started making typos. By the end I had a bug in the u128 variant that took another hour to find. That’s the day I actually sat down and learned macros properly.

The Gap Between Functions and Macros

Functions are great. You take some inputs, do some work, return a result. But functions operate on values. 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.

Lesson 16: How Async Executors Work Under the Hood — Demystifying the runtime

Tue, 04 Feb 2025 13:56:18 +0000

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, Waker, Context, poll_ready — all of it made sense. Not as abstract concepts, but as mechanical parts.

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.

Lesson 15: Backpressure — Bounded channels and flow control

Sun, 02 Feb 2025 10:33:45 +0000

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.

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.

Lesson 14: Tower — The service middleware pattern

Fri, 31 Jan 2025 19:18:37 +0000

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.

Writing those as middleware that composes? That’s Tower’s whole thing. And once it clicks, you’ll never build a service without it.

Lesson 13: Building HTTP Clients with reqwest — Async HTTP done right

Thu, 30 Jan 2025 16:42:09 +0000

Almost every backend service I’ve built makes HTTP calls to something — 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.

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.

Lesson 12: Async I/O — Files, sockets, DNS

Tue, 28 Jan 2025 08:55:13 +0000

Here’s an uncomfortable truth about async file I/O: on most operating systems, it doesn’t really exist. When you call tokio::fs::read_to_string, 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.

Understanding this distinction matters. It changes how you architect things.

The Async I/O Traits

Tokio defines two core traits that mirror their std counterparts:

Lesson 11: Timeouts, Deadlines, and Graceful Shutdown — Bounded operations

Sun, 26 Jan 2025 12:24:51 +0000

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.

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 well.”

Lesson 10: Cancellation Safety — The silent footgun

Fri, 24 Jan 2025 09:41:22 +0000

This is the lesson I wish someone had shoved in my face before I wrote my first select! loop. I lost three days to a bug where messages were disappearing from a queue. No errors. No panics. Just… gone. Turns out, select! was cancelling a future that had already read the message from the channel but hadn’t finished processing it.

Cancellation safety is the most under-discussed footgun in async Rust. If you use select!, you need to understand this.

Lesson 9: Semaphores and Rate Limiting — Bounded async concurrency

Wed, 22 Jan 2025 15:08:36 +0000

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.

The fix was a single type: tokio::sync::Semaphore. Five lines of code turned “as fast as possible” into “at most N at a time.”

What’s a Semaphore?

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.

Lesson 8: Async Mutexes — tokio::sync::Mutex vs std

Mon, 20 Jan 2025 07:15:44 +0000

“Should I use tokio::sync::Mutex or std::sync::Mutex 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.

The real answer depends on how long you hold the lock and whether you need to .await while holding it. Get this wrong and you’ll either deadlock your runtime or tank your performance.

Lesson 7: Async Channels — tokio::sync::mpsc

Sat, 18 Jan 2025 13:52:28 +0000

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 also channels — but you’ve got four different kinds to choose from, and picking the wrong one leads to subtle bugs.

This lesson covers all four of Tokio’s channel types and when to reach for each one.

Lesson 6: Streams — Async iterators

Thu, 16 Jan 2025 10:31:07 +0000

Regular iterators give you one value at a time, synchronously. Futures give you one value, asynchronously. Streams give you multiple 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.

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.

Lesson 5: tokio::select! — Racing futures

Tue, 14 Jan 2025 16:19:55 +0000

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 join!, I’d need all three to complete. But I didn’t want them all to complete — I wanted to react to whichever one happened first.

That’s what select! does. It races multiple futures and gives you the result of the winner. The losers are dropped.

Lesson 4: Spawning Tasks and JoinHandles — Concurrent work units

Sun, 12 Jan 2025 08:44:19 +0000

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.

But spawning tasks isn’t free, and JoinHandle has some sharp edges that nobody warned me about. This lesson covers the patterns you’ll use every day.

Lesson 3: Tokio — The runtime that powers async Rust

Fri, 10 Jan 2025 11:05:33 +0000

Every async Rust tutorial shows you #[tokio::main] in the first example and then moves on like that’s totally self-explanatory. It’s not. That macro hides a lot of important decisions, and if you don’t understand what it’s doing, you’re going to make some costly mistakes.

I once spent an entire day debugging a deadlock that happened because I was using the single-threaded runtime without realizing it. One #[tokio::main(flavor = "current_thread")] vs the default, and my entire application’s behavior changed. That shouldn’t surprise anyone — but it surprised me.

Lesson 2: The Future Trait — What .await actually does

Wed, 08 Jan 2025 14:37:42 +0000

After I understood the mental model from lesson 1, my next question was obvious: what happens mechanically when I write .await? I could accept “it’s a state machine” as a hand-wave, but I wanted to see the gears turning.

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.

The Future Trait, For Real This Time

use std::pin::Pin;
use std::task::{Context, Poll};

pub trait Future {
 type Output;
 fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}

Three things to note:

Lesson 1: Async Mental Model — Futures, not threads

Mon, 06 Jan 2025 09:22:14 +0000

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 async fn, slapping .await on things, and hoping for the best. Sound familiar?

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 wrong for Rust.

Lesson 25: Production Concurrency Architecture — Putting it all together

Sun, 22 Dec 2024 10:00:00 +0000

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.

This lesson is the blueprint I wish I’d had when I started building concurrent Rust systems for real.

Lesson 24: Testing Concurrent Code — Loom and beyond

Sat, 21 Dec 2024 09:15:00 +0000

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.

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 for that particular thread scheduling. Run the same test with different timing and you might get a different result.

Lesson 23: GPU Computing from Rust — wgpu and compute shaders

Thu, 19 Dec 2024 11:35:00 +0000

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.

Rust’s GPU story has gotten remarkably good. wgpu gives you cross-platform GPU compute that works on Vulkan, Metal, DX12, and even in the browser via WebGPU. No CUDA lock-in.

Lesson 22: SIMD — Explicit vectorization

Tue, 17 Dec 2024 08:20:00 +0000

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.

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.

Lesson 21: CSP-Style Concurrency — Go channels in Rust

Sun, 15 Dec 2024 10:40:00 +0000

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 select statement. Crossbeam has it — and in some ways it’s even better.

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.

Lesson 20: The Actor Model with Rust — Message-passing architectures

Fri, 13 Dec 2024 14:20:00 +0000

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.

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.

Lesson 19: Thread-Local Storage — Per-thread state

Wed, 11 Dec 2024 09:55:00 +0000

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.

Thread-local storage is the ultimate escape hatch from synchronization overhead. If each thread has its own copy, there’s nothing to synchronize.

Lesson 18: Debugging Deadlocks and Data Races — Tools and techniques

Mon, 09 Dec 2024 11:30:00 +0000

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.

Lesson 17: Lock-Free Data Structures in Rust — Beyond mutexes

Sat, 07 Dec 2024 08:50:00 +0000

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.

That’s when lock-free data structures become worth the complexity. When the lock is the bottleneck, remove the lock.

Lesson 16: Barriers and Once — Synchronization primitives

Thu, 05 Dec 2024 10:15:00 +0000

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.

That’s what barriers do. Everyone waits at the barrier until the last thread arrives, then they all proceed together.

Lesson 15: Condvar — Waiting for conditions

Tue, 03 Dec 2024 14:40:00 +0000

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.

Lesson 14: parking_lot — Faster mutexes

Sun, 01 Dec 2024 09:25:00 +0000

I switched a high-contention service from std::sync::Mutex to parking_lot::Mutex 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.

parking_lot 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.

Lesson 13: Fan-Out Fan-In in Rust — Parallel pipelines

Fri, 29 Nov 2024 12:50:00 +0000

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.

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.

Lesson 12: Worker Pool Patterns — Bounded concurrency

Wed, 27 Nov 2024 08:35:00 +0000

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 for item in items { thread::spawn(...) } without thinking about bounds.

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.

Lesson 11: Crossbeam — Scoped threads and lock-free structures

Mon, 25 Nov 2024 11:05:00 +0000

Before Rust 1.63 added thread::scope 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 std::sync::mpsc, it provides lock-free data structures, and its utilities fill gaps the standard library doesn’t cover.

I reach for crossbeam in nearly every concurrent Rust project. Here’s why.

Crossbeam Channels

The biggest win: crossbeam’s channels are multi-producer, multi-consumer (MPMC) and significantly faster than std::sync::mpsc.

Lesson 10: Rayon — Data parallelism made easy

Sat, 23 Nov 2024 15:20:00 +0000

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 .iter() to .par_iter(), and it dropped to 90 seconds. Five characters added to my code. That’s it.

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.

Lesson 9: Send and Sync — The traits behind thread safety

Thu, 21 Nov 2024 09:40:00 +0000

There’s a moment in every Rust developer’s life when they try to send an Rc<RefCell<Vec<String>>> to another thread and get a wall of compiler errors. They Google the error, see something about Send and Sync, patch the type to Arc<Mutex<Vec<String>>>, and move on without understanding why.

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.

Lesson 8: Memory Ordering — Relaxed, Acquire, Release, SeqCst

Tue, 19 Nov 2024 13:15:00 +0000

Memory ordering is the thing that separates people who use concurrent code from people who write concurrent primitives. I avoided understanding it for years, using SeqCst 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.

So here’s the actual explanation — no hand-waving.

Why Ordering Matters

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.

Lesson 7: Atomics — Lock-free primitives

Sun, 17 Nov 2024 07:45:00 +0000

I once replaced a Mutex<u64> counter in a hot path with an AtomicU64 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.

Atomics are the foundation of lock-free programming. They let you do thread-safe operations on primitive values without any lock at all.

Lesson 6: Arc> — The shared mutable state pattern

Fri, 15 Nov 2024 10:30:00 +0000

I remember staring at Arc<Mutex<HashMap<String, Vec<u8>>>> 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.

The Arc<Mutex<T>> pattern is everywhere in Rust concurrent code. Understanding why it exists — not just how to type it — is the key.

Lesson 5: Shared State — Mutex, RwLock, and poisoning

Wed, 13 Nov 2024 16:55:00 +0000

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 access pattern was broken.

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.

Lesson 4: Channels — mpsc and beyond

Mon, 11 Nov 2024 09:10:00 +0000

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.

That experience sold me on message passing. And Rust’s channel implementation makes it surprisingly ergonomic.

The Problem: Shared State Is Hard

You can 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.

Lesson 10: Redis, MongoDB, and Non-Relational Stores — Beyond SQL

Sun, 10 Nov 2024 15:37:00 +0000

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.

Not every data problem is a SQL problem. Sometimes you need the right tool, not a better query plan.

Lesson 3: move Closures — Sending data to threads

Sat, 09 Nov 2024 14:20:00 +0000

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 move on closures until things compiled, without really understanding what was happening.

That’s a terrible way to learn. So here’s the actual explanation I wish I’d had.

The Problem: Closures and Thread Lifetimes

When you pass a closure to thread::spawn, 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.

Lesson 2: std::thread — Spawning and joining

Thu, 07 Nov 2024 11:45:00 +0000

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 so easy to fire off concurrent work that nobody stopped to think about cleanup.

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.

Lesson 9: N+1 Queries, Indexes, and EXPLAIN — Database performance in Rust

Wed, 06 Nov 2024 07:52:00 +0000

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.

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.

Lesson 1: Why Rust Concurrency Is "Fearless" — The compiler has your back

Tue, 05 Nov 2024 08:30:00 +0000

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.

Then I tried to write the same bug in Rust. The compiler said no.

Lesson 8: Testing with Real Databases — No more mocking SQL

Sun, 03 Nov 2024 13:15:00 +0000

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 DISTINCT 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.

That was when I stopped mocking SQL.

The Problem with Mocking Database Calls

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.

Lesson 7: Building Type-Safe Query Builders — Queries that can't be wrong

Fri, 01 Nov 2024 09:28:00 +0000

I was reviewing a PR that had a search endpoint with 12 optional filters. The handler was a 200-line function full of if let Some(...) blocks, each appending a different SQL fragment to a String. It worked — until someone forgot a space between AND 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.

Lesson 6: The Repository Pattern in Rust — Abstracting persistence

Wed, 30 Oct 2024 16:40:00 +0000

I once inherited a codebase where every HTTP handler had raw SQL queries inline — sqlx::query! 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.

The repository pattern fixes this. It puts a wall between your business logic and your database, and that wall pays for itself fast.

Lesson 5: Transactions and Error Rollback — Atomic operations

Mon, 28 Oct 2024 10:05:00 +0000

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.

The fix was embarrassingly simple: wrap both operations in a transaction.

Lesson 12: Production Deployment — Docker, graceful shutdown, observability

Mon, 28 Oct 2024 08:55:00 +0000

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.

Dockerfile: The Multi-Stage Build

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.

Lesson 4: Schema Migrations in Rust Projects — Evolving your database

Sat, 26 Oct 2024 19:12:00 +0000

A teammate once ran ALTER TABLE orders DROP COLUMN status 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.

Schema migrations exist to prevent exactly this — they’re version control for your database.

The Problem

Your database schema isn’t static. Features get added, requirements change, data models evolve. You need a way to:

Lesson 11: Integration Testing HTTP Services — Testing without mocks

Thu, 24 Oct 2024 15:40:00 +0000

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.

Lesson 3: Connection Pooling with deadpool and bb8 — Managing database connections

Thu, 24 Oct 2024 14:35:00 +0000

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 pg_stat_activity showed 200+ connections churning constantly. The fix took ten lines of code: add a connection pool.

Lesson 2: Diesel — The ORM approach

Tue, 22 Oct 2024 08:47:00 +0000

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?”

He was right. Sometimes you don’t want to write SQL. Sometimes you want the boilerplate to disappear.

Lesson 10: OpenAPI / Swagger Generation — Documentation from code

Mon, 21 Oct 2024 10:05:00 +0000

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.

The Approach: utoipa

utoipa 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.

Lesson 1: SQLx — Compile-time checked queries

Sun, 20 Oct 2024 11:23:00 +0000

I shipped a typo in a SQL column name to production last year. The column was user_nme instead of user_name. 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.

That was the day I started using SQLx in Rust. I haven’t shipped a SQL typo since.

Lesson 9: Rate Limiting and Throttling — Protecting your service

Fri, 18 Oct 2024 13:10:00 +0000

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.

Why Rate Limit

Three reasons, in order of importance:

Lesson 8: WebSockets with Axum — Real-time in Rust

Wed, 16 Oct 2024 09:20:00 +0000

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.

Lesson 7: Pagination, Filtering, and Sorting — API patterns that scale

Mon, 14 Oct 2024 16:30:00 +0000

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.

Offset-Based Pagination

The most common approach. Simple to implement, easy to understand, and good enough for most internal tools and admin panels.

Lesson 6: Database Integration — SQLx and connection management

Sat, 12 Oct 2024 07:45:00 +0000

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.

Why SQLx

There are three main approaches to database access in Rust:

Diesel — 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.
SeaORM — An async ORM inspired by ActiveRecord. Higher level, more magic. Good if you like ORMs.
SQLx — 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.

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.

Lesson 5: Authentication — JWT, sessions, OAuth

Wed, 09 Oct 2024 11:00:00 +0000

I’ve reviewed auth implementations at four different companies. Three of them stored passwords in SHA-256 without salting. One stored them in plain text in a column called password_encrypted — 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.

Password Hashing: Do This Right or Don’t Do It At All

Before we talk about tokens or sessions, let’s nail password storage. The rules are simple and non-negotiable:

Lesson 10: Conversion Traits — From, Into, TryFrom, AsRef

Tue, 08 Oct 2024 15:30:00 +0000

I used to litter my Rust code with .to_string(), as, 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.

From and Into — Infallible Conversion

From<T> defines how to create a type from another type. It can’t fail. If there’s any possibility of failure, you want TryFrom instead.

Lesson 4: Request Validation and Error Responses — Clean input handling

Mon, 07 Oct 2024 19:15:00 +0000

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.

The Problem with Default Error Responses

Out of the box, Axum’s error responses are… not great. Send malformed JSON to a Json<T> handler and you get back:

Lesson 3: Middleware with Tower Layers — The composable middleware pattern

Sat, 05 Oct 2024 08:30:00 +0000

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 composable and type-checked. You can’t silently swallow errors when the type system forces you to handle them.

Lesson 9: std::sync — Mutex, RwLock, Once, Barrier

Fri, 04 Oct 2024 13:25:00 +0000

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.

Arc — Shared Ownership Across Threads

Before we talk about locks, we need Arc. You can’t share data between threads with just Rc — it’s not thread-safe. Arc (Atomic Reference Counted) is the thread-safe version.

Lesson 2: Axum from Zero — Routing, handlers, extractors

Thu, 03 Oct 2024 14:45:00 +0000

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.

Routing Fundamentals

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.

Lesson 1: The Rust Web Landscape — Axum, Actix, Rocket and why I pick Axum

Tue, 01 Oct 2024 10:22:00 +0000

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 with it.

Lesson 8: std::time — Duration, Instant, SystemTime

Tue, 01 Oct 2024 07:50:00 +0000

A few months ago I tracked down a bug where a cache TTL check was wrong because someone compared SystemTime 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.

Two Clocks, Two Types

Rust gives you two time types because computers have two fundamentally different clocks:

Lesson 7: std::process — Running external commands

Sun, 29 Sep 2024 19:15:00 +0000

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 std::process::Command — same functionality, but with actual error handling and type safety. The number of failed deployments dropped to zero.

Command — The Builder

std::process::Command 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.

Lesson 6: std::net — TCP, UDP, sockets

Fri, 27 Sep 2024 09:40:00 +0000

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 std::net module gives you the same low-level socket primitives, but the ownership system actually helps you avoid some of those pitfalls.

TCP — The Reliable One

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.

Lesson 5: std::fmt — Formatting internals

Tue, 24 Sep 2024 11:05:00 +0000

I once shipped a monitoring dashboard where all the latency values showed up as “Duration { secs: 0, nanos: 234000000 }” because I’d used {:?} instead of implementing Display. That’s the kind of thing that makes you sit down and actually learn how formatting works.

Display vs. Debug

These two traits are the foundation of everything in std::fmt. Every time you use println!, format!, or write!, you’re invoking one of them.

Lesson 10: Testing CLI Applications — End-to-end CLI tests

Sun, 22 Sep 2024 12:10:00 +0000

I shipped a CLI tool with 100% unit test coverage on the core logic. Users immediately found three bugs. The argument parser accepted --port but the value wasn’t being passed to the server. The --json flag produced output that wasn’t valid JSON because of a stray debug print. And --help showed the wrong default for --timeout. 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.

Lesson 4: std::fs and std::path — Filesystem operations done right

Sat, 21 Sep 2024 16:10:00 +0000

A colleague once deployed a script that used string concatenation for file paths: dir + "/" + filename. Worked perfectly on Linux, blew up on Windows, and silently corrupted paths when dir ended with a slash. Rust’s Path type exists specifically to prevent this class of bug.

Path vs. PathBuf — The &str/String Split

Just like Rust has &str (borrowed) and String (owned), it has &Path (borrowed) and PathBuf (owned). The duality is identical:

Lesson 3: std::io — Read, Write, BufRead, Seek

Thu, 19 Sep 2024 08:30:00 +0000

Early in my Rust journey, I wrote a log parser that read a 2GB file byte by byte using read() without buffering. It took forty minutes. Adding a BufReader wrapper — one line of code — brought it down to three seconds. That’s when I learned that understanding std::io isn’t optional.

The Four Core Traits

Rust’s I/O system is built on four traits. Everything — files, network sockets, stdin, pipes, in-memory buffers — implements some combination of these:

Lesson 9: Building TUIs with ratatui — Terminal user interfaces

Thu, 19 Sep 2024 07:55:00 +0000

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.

Lesson 2: Iterator Trait and Adapters — The full picture

Tue, 17 Sep 2024 14:45:00 +0000

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.

The Iterator Trait

Everything starts here. The Iterator trait is shockingly simple:

Lesson 8: Distribution — Static binaries, cargo-dist, Homebrew

Mon, 16 Sep 2024 19:40:00 +0000

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 brew install myapp, most people won’t bother.

Lesson 1: Collections Deep Dive — Vec, VecDeque, BTreeMap and when to use which

Sun, 15 Sep 2024 10:22:00 +0000

I spent two days debugging a performance cliff in a data pipeline — turns out I’d been using a HashMap where a BTreeMap would’ve cut iteration time in half because I needed sorted output downstream. The collection you pick matters more than most people think.

The Big Picture

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.

Lesson 7: Cross-Compilation for Linux, Mac, Windows — Build once, run anywhere

Sat, 14 Sep 2024 10:25:00 +0000

First time I tried to cross-compile a Rust binary from my Mac to Linux, I ran cargo build --target x86_64-unknown-linux-gnu and got hit with a wall of linker errors. Missing cc, wrong libc, something about crt1.o. 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.

How Rust Compilation Works

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 linker.

Lesson 6: Subcommands and Complex CLI Structures — git-style interfaces

Wed, 11 Sep 2024 13:50:00 +0000

Every tool starts as mytool --flag input.txt. Then someone asks for a second mode. Then a third. Before you know it, you have mytool --mode=convert --input foo --output bar and mytool --mode=validate --strict --input foo and users are scrolling through --help trying to find the three flags that matter for their use case. The answer is subcommands. git commit, docker build, cargo test — separate commands with separate flags, unified under one binary.

Lesson 5: Signal Handling and Graceful Shutdown — Clean exits

Mon, 09 Sep 2024 09:17:00 +0000

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.

What Happens When You Press Ctrl+C

When you press Ctrl+C in a terminal, the kernel sends SIGINT (signal interrupt) to the foreground process group. By default, this kills your program immediately. No destructors run. No Drop implementations execute. Temporary files stay on disk. Database connections aren’t closed. Partial writes aren’t rolled back.

Lesson 12: Test Architecture — When to unit, integration, or e2e

Sun, 08 Sep 2024 11:10:00 +0000

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 more tests than any codebase I’d seen — and also more bugs. The volume was high, but the strategy was garbage.

Lesson 4: Colored Output and Progress Bars — UX for the terminal

Sat, 07 Sep 2024 16:33:00 +0000

I used to think terminal output was either plain text or ANSI escape code soup. Then I looked at how tools like cargo, ripgrep, and bat 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.

Raw ANSI Escape Codes

Before using any crate, you should understand what’s actually happening. Terminal colors are just special byte sequences embedded in the output stream:

Lesson 11: Testing in CI — GitHub Actions for Rust

Thu, 05 Sep 2024 16:45:00 +0000

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 std::path::PathBuf 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.

Lesson 3: Configuration Files and Environment Variables — Config that scales

Thu, 05 Sep 2024 11:08:00 +0000

I shipped a CLI tool with 23 flags once. Twenty-three. The --help 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.

The Configuration Hierarchy

Every serious CLI tool follows the same precedence order:

Command-line flags (highest priority)
Environment variables
Project-local config file (.myapp.toml in the current directory)
User config file (~/.config/myapp/config.toml)
System config file (/etc/myapp/config.toml)
Compiled-in defaults (lowest priority)

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.

Lesson 2: stdin, stdout, stderr — I/O patterns

Tue, 03 Sep 2024 08:45:00 +0000

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 String before processing a single line. Classic.

Why I/O Is Harder Than It Looks

Unix tools work because of a simple contract: read from stdin, write to stdout, errors to stderr. cat file | grep pattern | sort | uniq -c. Each program does one thing. They compose through pipes. It’s beautiful when it works.

Lesson 10: Benchmarking with criterion — Measure, don't guess

Mon, 02 Sep 2024 13:20:00 +0000

I once optimized a hot loop by replacing a HashMap lookup with a Vec indexed by a precomputed key. Felt clever. Ran the benchmarks. The “optimized” version was 15% slower because the Vec 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.

The Problem

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.

Lesson 1: clap — Argument parsing done right

Sun, 01 Sep 2024 14:22:00 +0000

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.

The Problem With Rolling Your Own

Parsing command-line arguments seems simple. You grab std::env::args(), maybe split on =, handle some --flag and -f cases. Works great until someone passes --output= with no value. Or uses -vvv for triple verbosity. Or expects --help to just work. Or wants --color=always|never|auto. Suddenly your 40-line parser is 400 lines of spaghetti.

Lesson 9: Code Coverage — tarpaulin and llvm-cov

Fri, 30 Aug 2024 07:55:00 +0000

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 assert!(true) just to touch lines. We had 92% coverage and bugs everywhere. Coverage is a useful signal. It’s a terrible goal.

That said, knowing which 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.

Lesson 8: Snapshot Testing with insta — Catch regressions instantly

Tue, 27 Aug 2024 10:30:00 +0000

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.

Lesson 7: Fuzz Testing with cargo-fuzz — Breaking your code automatically

Sat, 24 Aug 2024 20:05:00 +0000

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.

Lesson 6: Property-Based Testing with proptest — Let the computer find your bugs

Thu, 22 Aug 2024 15:40:00 +0000

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.

The Problem

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 sort([3, 1, 2]) passes, but does your sort handle a list with ten million duplicates? A list of all negative numbers? An empty list? A list with i32::MAX and i32::MIN adjacent?

Lesson 5: Mocking — mockall and faking dependencies

Mon, 19 Aug 2024 08:15:00 +0000

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 RefCell<Vec<...>> wrappers, wrote expectation-checking logic… and ended up with 200 lines of mock code to test 15 lines of business logic. Then I found mockall and felt like an idiot.

The Problem

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.

Lesson 4: Test Fixtures and Setup/Teardown — Reusable test infrastructure

Sat, 17 Aug 2024 11:30:00 +0000

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.

Fixtures exist to prevent this kind of insanity.

Lesson 3: Doc Tests — Tested documentation

Wed, 14 Aug 2024 18:10:00 +0000

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.

The Problem

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 String to &str, and the example in the docstring quietly becomes fiction. No compiler warning, no test failure, just a frustrated user copy-pasting broken code.

Lesson 2: Integration Tests — The tests/ directory

Mon, 12 Aug 2024 09:45:00 +0000

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.

The Problem

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 public API actually makes sense. You can have perfect internal functions that combine into a terrible user experience.

Lesson 1: Unit Tests — #[test] and assertions

Sat, 10 Aug 2024 14:22:00 +0000

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 assert_eq! and thirty seconds of effort.

Never again. Here’s how testing actually works in Rust, from the ground up.

Lesson 8: Refutable vs Irrefutable Patterns — Where they apply

Thu, 08 Aug 2024 12:40:00 +0000

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.”

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.

Lesson 7: The Visitor Pattern via Enums — When trait objects won't cut it

Mon, 05 Aug 2024 20:15:00 +0000

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.

The Problem: Open vs. Closed Hierarchies

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.

Lesson 6: State Machines with Enums — Compile-time guarantees

Fri, 02 Aug 2024 07:20:00 +0000

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.

If the state machine had been in the type system, that shortcut wouldn’t have compiled.

Lesson 5: Enums Carrying Data — Modeling real domains

Tue, 30 Jul 2024 09:55:00 +0000

The worst bug I ever shipped came from a status 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.

Rust enums would have made that bug impossible.

The Problem With Primitive Obsession

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:

Lesson 10: Production Error Architecture — Logging, reporting, recovery

Sun, 28 Jul 2024 11:30:00 +0000

I shipped a Rust service to production once with great error types, proper Result 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 types is half the battle. The other half is what you do with those errors when they reach the top of your stack.

Lesson 4: Or Patterns, @ Bindings, and Rest Patterns — The full syntax

Sat, 27 Jul 2024 14:10:00 +0000

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.

Most Rust developers learn the basics of match 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, @ bindings, and rest patterns.

Lesson 3: Match Guards and Bindings — Fine-grained control

Thu, 25 Jul 2024 08:30:00 +0000

A few months back I was writing a rate limiter. The logic was simple: if the request is from an internal IP and the rate is under the limit, allow it. If it’s external and under a different limit, allow it. Otherwise, reject. I started with nested if 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.

Lesson 9: panic!, unwrap, expect — When crashing is correct

Wed, 24 Jul 2024 07:55:00 +0000

There’s a pervasive myth in the Rust community that unwrap() is always bad. I’ve seen code reviews where people mechanically replace every unwrap() with a match or .expect(), even when the unwrap() was perfectly correct. The truth is more nuanced: panic! is a tool, and like any tool, the question isn’t “should I ever use it?” but “when is it the right choice?”

What panic! Actually Does

When you call panic!(), Rust does one of two things depending on your configuration:

Lesson 2: Destructuring — Structs, tuples, enums, nested

Mon, 22 Jul 2024 16:45:00 +0000

I used to write code like point.x, point.y, point.z 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.

Destructuring is opening the package and grabbing everything at once.

The Problem With Field-by-Field Access

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:

Lesson 8: Adding Context — Error chains and backtraces

Sun, 21 Jul 2024 13:10:00 +0000

Picture this: it’s 2 AM, your pager goes off, and the log says "connection refused". Connection to what? From where? During which operation? 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.

Lesson 1: match — Exhaustive by design

Sat, 20 Jul 2024 11:23:00 +0000

I shipped a Python service once that had a match 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.

Rust’s match wouldn’t have let that happen.

The Problem With Non-Exhaustive Matching

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.

Lesson 7: Library vs Application Error Strategy — They're not the same

Thu, 18 Jul 2024 09:40:00 +0000

I learned this the hard way. I was building a parsing library and used anyhow::Error 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.

Libraries and applications have fundamentally different error handling requirements. Mix them up and you’ll either frustrate your users or drown in unnecessary boilerplate.

Lesson 6: anyhow — When you don't care about the type

Tue, 16 Jul 2024 16:20:00 +0000

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 anyhow. Same author as thiserror (David Tolnay), completely different use case. Where thiserror is for defining precise error types, anyhow is for using errors without ceremony.

The Problem anyhow Solves

Without anyhow, when you have a function that can fail in multiple unrelated ways, you either:

Lesson 5: thiserror — Derive your way to clean errors

Sun, 14 Jul 2024 10:00:00 +0000

After writing my third custom error type by hand — with the Display impl, the Error impl, the From impls — I thought, “there has to be a better way.” There was. It’s called thiserror, 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.

What thiserror Does

thiserror is a derive macro that generates Display, Error, and From 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).

Lesson 15: GATs — Generic associated types explained

Fri, 12 Jul 2024 18:00:00 +0000

GATs (Generic Associated Types) took seven years 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.

The one-liner: GATs let associated types have their own generic parameters, including lifetimes.

Lesson 4: Designing Custom Error Types — Your domain, your errors

Thu, 11 Jul 2024 19:15:00 +0000

I once worked on a project where every error was Box<dyn std::error::Error>. Debugging was miserable. When something failed in production, the logs said things like “invalid input” with zero context about which input, where in the pipeline, or why it was invalid. That’s when I learned that good error types aren’t an afterthought — they’re part of your domain model.

Why Custom Error Types Matter

Standard library errors like io::Error and ParseIntError 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.

Lesson 14: Const Generics — Types parameterized by values

Wed, 10 Jul 2024 15:30:00 +0000

Before const generics landed (Rust 1.51), working with arrays was painful. You couldn’t write a function that accepted [T; N] for any N. The standard library had trait implementations for arrays up to size 32 — manually written, one per size. Need [u8; 33] to implement Debug? Too bad. That era is over, and honestly, const generics are one of the most underappreciated features in modern Rust.

Instead of parameterizing types by other types, you parameterize them by values. An array’s size, a buffer’s capacity, a matrix’s dimensions — baked into the type system at compile time.

Lesson 3: The ? Operator — Propagation made elegant

Tue, 09 Jul 2024 14:30:00 +0000

Before the ? operator existed, Rust had try!() — a macro that did the same thing but looked ugly and nested poorly. When ? 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 match blocks and try!() calls, and the code just… breathed.

What ? Actually Does

The ? operator is syntactic sugar for early return on error. When you write this:

Lesson 13: Monomorphization — How generics become fast

Sun, 07 Jul 2024 11:45:00 +0000

“Zero-cost abstractions” is Rust’s battle cry. But what does that actually mean for generics? How does Vec<i32> and Vec<String> 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.

This is brilliant. It’s also a double-edged sword. And understanding the mechanism changes how you design generic APIs.

Lesson 2: Result and Option — The foundation

Sun, 07 Jul 2024 08:45:00 +0000

When I first started writing Rust, I used match on every single Result and Option. 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.

Result: More Than Just Ok and Err

You already know Result<T, E> has two variants. But Result comes with a huge set of methods that let you transform, combine, and short-circuit without writing explicit match blocks everywhere.

Lesson 1: Rust's Error Philosophy — No exceptions, no surprises

Fri, 05 Jul 2024 11:23:00 +0000

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 know 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.

Lesson 12: Operator Overloading with Traits — Making your types feel native

Thu, 04 Jul 2024 20:15:00 +0000

I was building a linear algebra library and got tired of writing vector_a.add(&vector_b) everywhere. It looked ugly. It read poorly. Math should look like math — a + b, not a.add(&b). In Rust, operator overloading isn’t some dark magic — it’s just trait implementation. Every operator maps to a trait in std::ops, and implementing that trait makes the operator work on your type.

The `Add` Trait

The + operator desugars to a call to Add::add:

Lesson 11: Essential Std Traits — Iterator, Display, From, Default

Tue, 02 Jul 2024 08:30:00 +0000

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 — Display, From, Default, Iterator. 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.

Lesson 10: Orphan Rules and the Newtype Workaround — Coherence in practice

Sun, 30 Jun 2024 17:55:00 +0000

Picture this: you’re using two crates — serde and some db_client crate. You want to implement serde::Serialize for db_client::Row. Sounds reasonable. You write the impl, 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.

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.”

Lesson 9: Blanket Implementations — Implementing for all T

Fri, 28 Jun 2024 10:20:00 +0000

The moment blanket implementations clicked for me, I felt like I’d been handed a cheat code. You write impl<T: Display> ToString for T and suddenly every single type that implements Display automatically gets ToString. One line of implementation logic, infinite types covered. This is how the standard library builds massive capability trees from small pieces.

What’s a Blanket Implementation?

A blanket implementation implements a trait for all types matching a bound, rather than for a specific type:

Lesson 8: Object Safety — Why some traits can't be dyn

Tue, 25 Jun 2024 13:40:00 +0000

The first time I got the error “the trait Clone 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 dyn? The answer is object safety — 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 why the rules exist.

Lesson 7: dyn Trait — Runtime polymorphism and its cost

Sun, 23 Jun 2024 19:15:00 +0000

Every Rust programmer hits this wall eventually. You have a Vec and you want to put different types in it — all implementing the same trait, but different concrete types. You try Vec<impl Trait> and the compiler says no. You try Vec<T> with generics and realize T can only be one type at a time. That’s when you discover dyn Trait, and the first real tradeoff in Rust’s type system: static dispatch vs dynamic dispatch.

Lesson 6: Supertraits — Building trait hierarchies

Fri, 21 Jun 2024 08:50:00 +0000

I had a trait called Serialize (homebrew, pre-serde days) that needed to format things as strings. I kept calling .to_string() inside default methods and wondering why the compiler complained. The type implementing my trait didn’t necessarily implement Display. The fix was obvious in hindsight — make Display a supertrait of Serialize. If you want to serialize, you must be displayable. Period.

Supertraits let you build trait hierarchies where implementing one trait requires implementing another.

Lesson 5: Associated Types vs Generic Parameters — Choosing the right tool

Wed, 19 Jun 2024 16:05:00 +0000

Here’s a question that confused me for months: why does Iterator use an associated type (type Item) instead of a generic parameter (Iterator<T>)? 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.

The short answer: associated types mean “one implementation per type,” generic parameters mean “many implementations per type.” But the implications are deeper than that.

Lesson 15: When You're Fighting the Borrow Checker — Restructure, Don't Hack

Tue, 18 Jun 2024 12:38:00 +0000

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 .clone() everywhere. You wrap things in Rc<RefCell<...>>. You consider unsafe.

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.

This lesson is a field guide. Real patterns that fight the borrow checker, and the restructurings that fix them.

Lesson 4: where Clauses — When bounds get complex

Mon, 17 Jun 2024 11:30:00 +0000

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 Hash + Eq + Clone + Debug on the key, Serialize + DeserializeOwned + Clone on the value, and Display on both. The inline bounds turned my function signature into an unreadable mess.

Lesson 3: Trait Bounds — Constraining generic types

Fri, 14 Jun 2024 21:10:00 +0000

I once wrote a generic function that looked perfectly reasonable — accepted any T, did some work, returned a result. It compiled. Then I tried to actually use it with a type that didn’t have Clone, 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.

Lesson 14: Pin and Unpin — Why Async Needs Them

Fri, 14 Jun 2024 20:05:00 +0000

Pin 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 why it exists requires connecting several ideas: self-referential structs, async/await desugaring, and move semantics.

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.

The Setup: What Async Really Does

When you write an async function:

Lesson 2: Default Implementations and Selective Overrides — Don't repeat yourself

Wed, 12 Jun 2024 14:45:00 +0000

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 identical method bodies. I was copying the same three lines into five impl blocks like a human xerox machine. There had to be a better way.

There is. Default implementations.

The Basics

A trait can provide a default body for any of its methods. Implementors can then choose to override it — or just accept the default:

Lesson 1: Trait Fundamentals — Defining shared behavior

Mon, 10 Jun 2024 09:22:00 +0000

I spent my first month in Rust writing impl 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.”

Lesson 13: Weak References — Breaking Cycles

Mon, 10 Jun 2024 09:15:00 +0000

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 Rc/Arc can’t do that.

Weak references are the solution. And honestly, if you understand why they exist, you understand half of what makes garbage collectors complex.

Lesson 12: Rc and Arc — Shared Ownership

Fri, 07 Jun 2024 17:50:00 +0000

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.

Single ownership doesn’t fit everything. Rc and Arc are Rust’s answer — reference-counted smart pointers that enable shared ownership with deterministic cleanup.

The Problem: Multiple Owners

// This doesn't work — who owns the shared config?
struct ServiceA {
 config: AppConfig, // owns it
}

struct ServiceB {
 config: AppConfig, // also owns a copy? expensive clone
}

You could pass references, but then you’re dealing with lifetimes everywhere. And if the config needs to outlive any individual service, you need 'static or owned data.

Lesson 11: Interior Mutability — Cell, RefCell, and the Rules

Tue, 04 Jun 2024 11:30:00 +0000

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 &T” rule is too restrictive.

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.

The Problem: Mutation Through &self

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:

Lesson 10: Self-Referential Structs — The Problem and Solutions

Sun, 02 Jun 2024 15:40:00 +0000

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.

I wasted two days on this in my second month of Rust. Let me save you those two days.

The Desire

You want a struct like this:

Lesson 9: Higher-Ranked Trait Bounds — for<'a> Explained

Fri, 31 May 2024 21:15:00 +0000

If regular lifetime annotations are Rust’s intermediate boss, for<'a> is the final boss. Higher-Ranked Trait Bounds (HRTBs) look terrifying in signatures, but they solve a very specific and real problem.

I avoided understanding HRTBs for over a year. Then I tried to write a function that takes a closure accepting references with any lifetime, and suddenly I had no choice. Let me save you that year.

The Problem

Say you want a function that accepts a closure. The closure takes a &str and returns something:

Lesson 8: 'static — Not What You Think

Wed, 29 May 2024 13:25:00 +0000

'static 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.

I’ve seen experienced Rust developers get this wrong. So don’t feel bad if it’s been confusing.

What ‘static Actually Means

'static means: “this reference is valid for the entire duration of the program.”

Lesson 7: Lifetimes in Structs — References That Live in Types

Mon, 27 May 2024 10:42:00 +0000

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 &str and wondering why the compiler kept yelling at me.

The fundamental tension: structs outlive function calls. References might not. The compiler needs you to prove the reference won’t dangle.

The Problem

// This won't compile
struct Excerpt {
 content: &str,
}

error[E0106]: missing lifetime specifier
 --> src/main.rs:2:14
 |
2 | content: &str,
 | ^ expected named lifetime parameter

Why? Because the compiler needs to know: how long does the thing content points to live? Without that information, it can’t guarantee the reference is valid for the struct’s entire lifetime.

Lesson 6: Lifetime Elision Rules — Why You Usually Don't Write 'a

Sat, 25 May 2024 19:08:00 +0000

If lifetimes are so important, why don’t you see 'a plastered all over most Rust code? Because the compiler is smart enough to figure it out 90% of the time.

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.

Lesson 5: Lifetime Annotations — Teaching the Compiler Relationships

Thu, 23 May 2024 08:55:00 +0000

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 'a.

Here’s the thing most tutorials get wrong: lifetime annotations don’t change how long anything lives. They describe relationships that already exist.

Why Lifetimes Exist

Consider this function:

Lesson 25: When to Reach for unsafe — And when not to

Wed, 22 May 2024 17:08:00 +0000

This is the lesson I almost didn’t write. Not because unsafe 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 unsafe blocks because the developer didn’t know the safe alternative existed. That’s the worst outcome.

But unsafe exists for a reason. Understanding when it’s appropriate — and more importantly, when it isn’t — is part of being a competent Rust developer.

Lesson 4: The Borrow Checker — What It's Really Doing

Tue, 21 May 2024 16:33:00 +0000

I used to think the borrow checker was my enemy. It rejected valid programs! It made simple things hard! It was too conservative!

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.

Borrowing: Using Without Owning

Ownership transfer is clean but inflexible. You can’t always afford to give your data away — sometimes you just want to let another function look at it for a moment. That’s borrowing.

Lesson 24: Writing Great Rust Documentation — rustdoc that actually helps

Mon, 20 May 2024 14:30:00 +0000

The Rust ecosystem has some of the best documentation I’ve seen in any language. And it’s not an accident — the tooling actively encourages 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.

If you’re publishing a crate and the docs are an afterthought, you’re doing it wrong. Documentation is the API.

Lesson 3: Copy vs Clone — When Data Gets Duplicated

Sun, 19 May 2024 11:10:00 +0000

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 — Copy and Clone.

Getting these confused will either tank your performance or confuse the hell out of you. Probably both.

Copy: Implicit, Cheap, and Bitwise

Copy 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.”

Lesson 23: Clippy Is Your Mentor — Listen to it

Sat, 18 May 2024 10:55:00 +0000

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.”

Run cargo clippy on every project. Every commit. No exceptions.

What Clippy Is

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.

Lesson 2: Move Semantics — Why Assignment Transfers Ownership

Fri, 17 May 2024 14:45:00 +0000

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 let b = a make a invalid?

This universe. Rust’s universe. And honestly — it’s the only sane default.

What a Move Actually Is

In most languages, let b = a copies the data or copies a reference. In Rust, for heap-allocated types, it moves the ownership. The bits get copied (the stack portion — pointer, length, capacity), but the old variable is invalidated.

Lesson 22: Feature Flags and Conditional Compilation — cfg and features

Thu, 16 May 2024 12:45:00 +0000

I once worked on a crate that pulled in 200+ transitive dependencies because it unconditionally depended on tokio, serde, reqwest, and tracing. Most users only needed one of those. The compile time was brutal, and the binary was enormous.

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.

cfg — Conditional Compilation

The #[cfg(...)] attribute conditionally includes code based on compile-time configuration:

Lesson 1: The Mental Model — Stack, Heap, and Ownership

Wed, 15 May 2024 09:22:00 +0000

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.

That’s backwards. You don’t learn ownership by memorizing rules. You learn it by understanding where your data actually lives.

Where Data Lives Changes Everything

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.

Lesson 21: The Turbofish ::<> — Explicit type parameters

Tue, 14 May 2024 08:22:00 +0000

The first time I saw ::<> in Rust code, I thought someone was having a stroke at the keyboard. collect::<Vec<_>>()? What is that colon-colon-angle-bracket monstrosity?

It’s called the turbofish. Named by the community because ::<> looks like a fish (::<> — see the eyes and the mouth?). It’s goofy. It’s lovable. And once you understand it, you’ll use it constantly.

What the Turbofish Does

The turbofish provides explicit type parameters to generic functions or methods when the compiler can’t infer them.

Lesson 20: API Design Guidelines — The Rust way

Sun, 12 May 2024 16:40:00 +0000

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.

Here’s what I’ve distilled from reading hundreds of crate APIs and writing a few of my own.

Naming Conventions

Rust has strong naming conventions, and deviating from them makes your crate feel alien.

Lesson 19: PhantomData — Tagging types without runtime cost

Fri, 10 May 2024 09:15:00 +0000

When I first saw PhantomData 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.

We already used it in the typestate lesson. Now let’s understand it properly.

Lesson 18: Drop and RAII — Deterministic cleanup

Wed, 08 May 2024 11:30:00 +0000

In Go, you write defer f.Close() and hope you didn’t forget one. In Python, you use with blocks and hope the context manager is implemented correctly. In Java, you use try-with-resources and hope AutoCloseable.close() doesn’t throw. In C, you write free() and pray.

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 Drop trait is how Rust implements it.

Lesson 17: Zero-Cost Abstractions — What it actually means

Mon, 06 May 2024 14:52:00 +0000

“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: you don’t pay for what you don’t use, and what you do use, you couldn’t hand-code any better.

That’s a Bjarne Stroustrup quote, originally about C++. But Rust actually delivers on it in ways C++ often doesn’t.

What Zero-Cost Actually Means

Consider iterators. In Python, iterator chains create intermediate objects. In Java, streams can have overhead from boxing and virtual dispatch. In Rust:

Lesson 16: Enums Over Booleans — Make illegal states unrepresentable

Sun, 05 May 2024 08:17:00 +0000

I once spent an entire afternoon debugging a function with this signature: process(data, true, false, true). Three booleans. What did they mean? I had to read the function definition every single time I encountered a call site. Is true for “verbose”? For “dry-run”? For “force”?

Booleans are the most overused type in programming. They encode exactly one bit of information — yes or no — and they tell you nothing about what question they’re answering. Enums fix this.

Lesson 15: Exhaustive Matching — Let the compiler help

Fri, 03 May 2024 22:08:00 +0000

A teammate once added a new payment method to our system — CryptoCurrency — and forgot to update the fee calculation logic. In production. For three weeks. Nobody noticed because the switch statement in Java had a default case that silently applied a 0% fee. Free crypto transfers for everyone.

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.

Lesson 14: derive Is Your Best Friend — The macros you should always use

Thu, 02 May 2024 10:30:00 +0000

I review a lot of Rust code, and one of my biggest pet peeves is types without #[derive(Debug)]. 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.

Just derive it from the start. Derive liberally. Your future self will thank you.

The Derives You Should Almost Always Use

Here’s my standard starting point for any struct or enum:

Lesson 13: Display and Debug — Formatting done right

Tue, 30 Apr 2024 18:45:00 +0000

Pop quiz: what’s the difference between {} and {:?} in a println!? If your answer is “one looks prettier,” you’re not wrong — but you’re missing the bigger picture.

Display and Debug serve fundamentally different audiences. Display is for humans — end users, log readers, UI consumers. Debug 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.

Lesson 12: Designing Error Types — thiserror vs anyhow

Mon, 29 Apr 2024 12:18:00 +0000

I’ve seen two extremes in Rust error handling. On one end: Box<dyn std::error::Error> 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 Display and From implementations, an over-engineered cathedral of boilerplate.

The right answer is somewhere in the middle. And the two crates that get you there are thiserror and anyhow.

The Wrong Ways

Wrong Way #1: String Errors

fn parse_config(input: &str) -> Result<u16, String> {
 let port: u16 = input.parse().map_err(|e| format!("bad port: {}", e))?;
 if port < 1024 {
 return Err("port must be >= 1024".to_string());
 }
 Ok(port)
}

The caller gets a String. 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.

Lesson 11: Cow — Clone on write for flexible APIs

Sat, 27 Apr 2024 15:33:00 +0000

There’s a function signature dilemma that every Rust developer hits: should this function return &str or String? If you return &str, you avoid allocation — but sometimes you need to create a new string. If you return String, you allocate every time — even when you don’t need to.

Cow says: “Why not both?”

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.

Lesson 10: Deref Coercion — Why &String works as &str

Thu, 25 Apr 2024 21:10:00 +0000

Here’s something that confused me for weeks when I started Rust: I’d write a function that takes &str, and I could pass it a &String. I’d write a function that takes &[i32], and I could pass it a &Vec<i32>. I’d use * to dereference a Box<T> and get a T.

How? Why? The answer is Deref coercion — one of Rust’s most elegant features, and one of the most poorly explained.

Lesson 9: From and Into — Seamless type conversions

Wed, 24 Apr 2024 07:55:00 +0000

The first time I saw .into() in Rust code, I was baffled. “Into what?” There was no type annotation, no explicit conversion function, just .into() hanging off a value like it knew exactly what to become. And somehow the compiler figured it out.

That’s the From/Into trait pair. It’s one of the most-used patterns in idiomatic Rust, and once you understand it, your APIs will feel dramatically smoother.

The Basics: `From` and `Into` Are Mirror Images

// If you implement From<A> for B...
impl From<i32> for MyType {
 fn from(value: i32) -> Self {
 MyType(value)
 }
}

// ...you get Into<B> for A for free
let x: MyType = 42.into();

Always implement From, never Into directly. The standard library provides a blanket implementation: if From<A> exists for B, then Into<B> is automatically available for A. Implementing Into directly doesn’t give you the reverse.

Lesson 8: The Builder Pattern in Rust — Ergonomic construction

Mon, 22 Apr 2024 19:42:00 +0000

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.

In Rust? You have options. And one of them is clearly better than the rest.

The Problem: Constructor Explosion

struct ServerConfig {
 host: String,
 port: u16,
 max_connections: usize,
 timeout_secs: u64,
 tls_enabled: bool,
 log_level: String,
 workers: usize,
}

// This is painful
fn main() {
 let config = ServerConfig {
 host: String::from("0.0.0.0"),
 port: 8080,
 max_connections: 1000,
 timeout_secs: 30,
 tls_enabled: false,
 log_level: String::from("info"),
 workers: 4,
 };
}

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.”

Lesson 7: The Newtype Pattern — Type safety for free

Sun, 21 Apr 2024 13:15:00 +0000

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.

You’d think we’d have learned. But I still see codebases where user IDs, product IDs, and order IDs are all i64. Where distances are f64 whether they’re meters or feet. Where an email address is just a String that you hope someone validated.

The newtype pattern fixes this. It gives you type safety with zero runtime cost.

Lesson 6: The Typestate Pattern — Compile-time state machines

Fri, 19 Apr 2024 10:28:00 +0000

I once spent two days debugging a production issue where someone called .send() on an HTTP request builder before 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.

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 types.

Lesson 25: Where to Go from Here — Your Rust learning path

Thu, 18 Apr 2024 18:00:00 +0000

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.

What You Know Now

Take a second to appreciate what you’ve learned. You can:

Set up a Rust project with Cargo
Write functions with proper ownership and borrowing
Model data with structs and enums
Handle errors with Result and the ? operator
Use collections: Vec, HashMap, HashSet
Write generic code with trait bounds
Process data with iterators and closures
Test your code with #[test]
Read and write files

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.

Lesson 5: Iterator Chains Over Manual Loops — Functional Rust

Thu, 18 Apr 2024 16:03:00 +0000

I used to write Rust like I was still writing C — for loops everywhere, mutable accumulators, index variables. The code worked, but it was loud. Five lines to express what should be one. Then I started using iterator chains, and honestly? I’m never going back.

Iterator chains aren’t just syntactic sugar. They’re often faster than hand-written loops because the compiler can optimize them better. Zero-cost abstractions in action.

The Imperative Way vs The Idiomatic Way

Here’s a task: given a list of strings, find all that start with “error:”, strip the prefix, trim whitespace, and collect the results.

Lesson 24: Reading and Writing Files — Real I/O in Rust

Tue, 16 Apr 2024 13:45:00 +0000

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 Result, iterators, and traits come together, the entire language design starts to feel cohesive.

Reading a File — The Quick Way

use std::fs;

fn main() {
 match fs::read_to_string("hello.txt") {
 Ok(content) => println!("File contents:\n{content}"),
 Err(e) => eprintln!("Error reading file: {e}"),
 }
}

fs::read_to_string reads the entire file into a String. It returns Result<String, io::Error> — because file operations can fail (file doesn’t exist, permission denied, disk error, etc.).

Lesson 4: if let and while let — Concise pattern matching

Tue, 16 Apr 2024 08:45:00 +0000

There’s a special kind of code smell that I call “match bloat” — when you write a six-line match 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.

If you’re writing match just to handle one case, you’re doing too much work.

The Problem: Match Bloat

Here’s code I see all the time, especially from developers coming from the previous lesson on Option and Result:

Lesson 3: Option and Result Are Your Control Flow — Stop using sentinel values

Sun, 14 Apr 2024 11:22:00 +0000

I once inherited a C codebase where -1 meant “not found,” 0 meant “error,” and NULL 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.

Rust looked at that mess and said: “How about we just… don’t.”

Lesson 23: Writing Your First Tests — #[test] and assert!

Sun, 14 Apr 2024 11:00:00 +0000

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.

Your First Test

fn add(a: i32, b: i32) -> i32 {
 a + b
}

#[cfg(test)]
mod tests {
 use super::*;

 #[test]
 fn test_add() {
 assert_eq!(add(2, 3), 5);
 }

 #[test]
 fn test_add_negative() {
 assert_eq!(add(-1, 1), 0);
 }

 #[test]
 fn test_add_zero() {
 assert_eq!(add(0, 0), 0);
 }
}

Run with cargo test:

Lesson 2: Borrow Strategically — &T, &mut T, and when to clone

Fri, 12 Apr 2024 14:37:00 +0000

A colleague once showed me their Rust code where every function parameter was String — never &str, never &String. When I asked why, they said “the borrow checker kept yelling at me, so I just take ownership of everything.” Classic.

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.

Lesson 22: Iterators — Lazy, composable data processing

Fri, 12 Apr 2024 09:30:00 +0000

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.

The Iterator Trait

At its core, an iterator is any type that implements the Iterator trait:

Lesson 21: Closures — Functions that capture

Wed, 10 Apr 2024 12:15:00 +0000

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 |x| x * 2 to .map() or |a, b| a.cmp(b) to .sort_by(), that was a closure. Time to understand what’s actually happening under the hood.

What Is a Closure?

A closure is an anonymous function that can capture variables from its surrounding scope:

Lesson 1: Think in Ownership — Not pointers

Wed, 10 Apr 2024 09:14:00 +0000

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 String was just “data on the heap.” Every function call was “passing a reference.” And every compiler error felt like Rust was being unreasonable.

It wasn’t. I was just thinking about memory the wrong way.

The C++/Java Mental Model (And Why It Fails)

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.

Lesson 20: Generics — Writing code that works for any type

Mon, 08 Apr 2024 20:00:00 +0000

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 f64 instead of i32. Generics aren’t luxury features — they’re how you stop writing the same function five times for five different types.

The Problem Generics Solve

Without generics, you write duplicate code:

fn largest_i32(list: &[i32]) -> &i32 {
 let mut largest = &list[0];
 for item in list {
 if item > largest {
 largest = item;
 }
 }
 largest
}

fn largest_f64(list: &[f64]) -> &f64 {
 let mut largest = &list[0];
 for item in list {
 if item > largest {
 largest = item;
 }
 }
 largest
}

fn main() {
 let ints = vec![34, 50, 25, 100, 65];
 let floats = vec![3.4, 5.0, 2.5, 10.0, 6.5];

 println!("Largest int: {}", largest_i32(&ints));
 println!("Largest float: {}", largest_f64(&floats));
}

These functions are identical except for the type. Generics let you write it once:

Lesson 19: Traits — Your first abstraction

Sun, 07 Apr 2024 15:45:00 +0000

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 is, traits define what data does.

What Is a Trait?

A trait defines a set of methods that a type can implement:

trait Greet {
 fn hello(&self) -> String;
}

struct Person {
 name: String,
}

struct Robot {
 id: u32,
}

impl Greet for Person {
 fn hello(&self) -> String {
 format!("Hi, I'm {}!", self.name)
 }
}

impl Greet for Robot {
 fn hello(&self) -> String {
 format!("UNIT-{} OPERATIONAL", self.id)
 }
}

fn main() {
 let person = Person { name: String::from("Alice") };
 let robot = Robot { id: 42 };

 println!("{}", person.hello());
 println!("{}", robot.hello());
}

The trait Greet declares that any implementing type must have a hello method. Person and Robot each provide their own implementation. Different types, same interface.

Lesson 18: Crates, Cargo.toml, and Dependencies — The Rust ecosystem

Fri, 05 Apr 2024 10:30:00 +0000

The first time I added a dependency in Rust, I was shocked. Add one line to Cargo.toml, run cargo build, and it downloads, compiles, and links everything automatically. Coming from C++ where dependency management is a special circle of hell, Cargo felt like cheating.

What Is a Crate?

A crate is a compilation unit in Rust — the smallest amount of code the compiler considers at a time. There are two kinds:

Lesson 17: Modules — Organizing your code

Wed, 03 Apr 2024 14:00:00 +0000

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.

Modules in a Single File

The simplest case — modules defined inline:

Lesson 16: Result and the ? Operator — Errors as values

Mon, 01 Apr 2024 08:45:00 +0000

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 (value, error) tuples, but then you’re back to forgetting to check the error. Rust’s Result type gets it right — errors are values, and the type system makes them impossible to ignore.

The Result Type

// Built into the language:
// enum Result<T, E> {
// Ok(T),
// Err(E),
// }

Result<T, E> is either Ok(T) (success with a value) or Err(E) (failure with an error). You’ve seen Option<T> — Result is similar but carries error information when something goes wrong.

Lesson 15: Vec, HashMap, and HashSet — The collections you'll use daily

Sat, 30 Mar 2024 11:15:00 +0000

In my experience, about 80% of all data structures in real programs are either lists or key-value maps. Rust nails both of them. Vec and HashMap are fast, safe, and ergonomic — and once you know these two plus HashSet, you can build almost anything.

Vec — The Dynamic Array

Vec<T> is Rust’s growable array. It stores elements contiguously on the heap, like ArrayList in Java or std::vector in C++.

Lesson 14: Methods and Associated Functions — impl blocks explained

Thu, 28 Mar 2024 17:30:00 +0000

In most object-oriented languages, data and behavior are bundled together inside classes. Rust separates them — you define data with struct (or enum) and attach behavior with impl 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.

Your First impl Block

#[derive(Debug)]
struct Rectangle {
 width: f64,
 height: f64,
}

impl Rectangle {
 fn area(&self) -> f64 {
 self.width * self.height
 }

 fn perimeter(&self) -> f64 {
 2.0 * (self.width + self.height)
 }

 fn is_square(&self) -> bool {
 (self.width - self.height).abs() < f64::EPSILON
 }
}

fn main() {
 let rect = Rectangle { width: 10.0, height: 5.0 };

 println!("Area: {}", rect.area());
 println!("Perimeter: {}", rect.perimeter());
 println!("Is square: {}", rect.is_square());
}

The impl Rectangle block defines methods for the Rectangle type. Inside the block, &self is a reference to the instance the method is called on. It’s equivalent to self: &Self, where Self is an alias for Rectangle.

Lesson 13: Pattern Matching — The match superpower

Tue, 26 Mar 2024 09:45:00 +0000

Pattern matching ruined switch statements for me. After using match 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.

Basic match

fn main() {
 let x = 3;

 match x {
 1 => println!("one"),
 2 => println!("two"),
 3 => println!("three"),
 _ => println!("something else"),
 }
}

_ is the catch-all pattern — it matches anything. Think of it as the default case in a switch statement, except it’s mandatory when the other arms don’t cover all possibilities.

Lesson 12: Enums and Option — Null safety by design

Mon, 25 Mar 2024 12:00:00 +0000

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.

Basic Enums

At their simplest, enums define a type that can be one of several variants:

#[derive(Debug)]
enum Direction {
 North,
 South,
 East,
 West,
}

fn describe(dir: &Direction) -> &str {
 match dir {
 Direction::North => "heading north",
 Direction::South => "heading south",
 Direction::East => "heading east",
 Direction::West => "heading west",
 }
}

fn main() {
 let d = Direction::North;
 println!("{:?}: {}", d, describe(&d));
}

If this is all enums did, they’d be equivalent to C enums. Mildly useful. Not exciting.

Lesson 11: Structs — Modeling your domain

Sat, 23 Mar 2024 20:15:00 +0000

I worked on a Go codebase once where someone had passed around a map[string]interface{} 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.

Defining a Struct

struct User {
 name: String,
 email: String,
 age: u32,
 active: bool,
}

fn main() {
 let user = User {
 name: String::from("Alice"),
 email: String::from("alice@example.com"),
 age: 30,
 active: true,
 };

 println!("{} ({}) - age {}", user.name, user.email, user.age);
}

Struct names are PascalCase. Field names are snake_case. These aren’t suggestions — the compiler warns you if you deviate.

Lesson 10: Strings — String vs &str and why it matters

Fri, 22 Mar 2024 15:30:00 +0000

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 more honest. Other languages hide the complexity of text. Rust makes you deal with it.

The Two String Types

Rust has two main string types:

String — owned, heap-allocated, growable, mutable
&str — borrowed, a slice/view into string data, immutable (usually)

fn main() {
 let owned: String = String::from("hello"); // heap-allocated, you own it
 let borrowed: &str = "hello"; // string literal, embedded in binary

 println!("{owned} {borrowed}");
}

The relationship between String and &str is exactly like Vec<u8> and &[u8]. A String is a buffer you own. A &str is a view into someone else’s string data (or a literal baked into your binary).

Lesson 9: Slices — Views into data

Wed, 20 Mar 2024 10:45:00 +0000

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.

What Is a Slice?

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.

Lesson 8: Borrowing and References — Sharing without giving

Mon, 18 Mar 2024 13:00:00 +0000

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.

References with &

A reference lets you refer to a value without owning it:

fn print_length(s: &String) {
 println!("Length of '{}': {}", s, s.len());
}

fn main() {
 let s = String::from("hello");
 print_length(&s); // lend s to the function
 println!("I still own: {s}"); // s is still valid
}

The & creates a reference. &s doesn’t move s — it creates a pointer to s that the function can use. When the function returns, the reference goes away but s remains untouched.

Lesson 7: Ownership — The rule that changes everything

Sat, 16 Mar 2024 08:30:00 +0000

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.

Why Ownership Exists

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).

Lesson 6: Control Flow — if, loop, while, for — and why there's no ternary

Thu, 14 Mar 2024 19:10:00 +0000

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 match, labeled loops, if let, and blocks-as-expressions — enough to keep your code flat and readable even when the logic is complex.

if / else

fn main() {
 let temperature = 35;

 if temperature > 30 {
 println!("It's hot");
 } else if temperature > 20 {
 println!("It's nice");
 } else {
 println!("It's cold");
 }
}

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.

Lesson 5: Functions, Expressions, and Statements — Everything is an expression

Wed, 13 Mar 2024 10:20:00 +0000

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.

Defining Functions

fn add(a: i32, b: i32) -> i32 {
 a + b
}

fn main() {
 let result = add(3, 7);
 println!("3 + 7 = {result}");
}

A few things to notice:

Lesson 4: Variables, Mutability, and Primitive Types — Let, let mut, and the type system

Mon, 11 Mar 2024 16:45:00 +0000

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.

Variables with let

fn main() {
 let x = 5;
 println!("x is {x}");
}

let creates a variable binding. It binds a name to a value. By default, that binding is immutable — you can’t change it.

Lesson 3: Hello, World — Anatomy of a Rust program

Sat, 09 Mar 2024 11:00:00 +0000

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.

The Program

fn main() {
 println!("Hello, world!");
}

That’s it. Three lines if you’re counting. But each piece tells you something about how Rust thinks.

Lesson 2: Installing Rust — rustup, cargo, and your first build

Thu, 07 Mar 2024 14:30:00 +0000

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.

Installing rustup

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.

Lesson 1: Why Rust Exists — And why you should care

Tue, 05 Mar 2024 09:15:00 +0000

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.

The Problem Rust Solves

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.

Mastering Rust: The Complete Guide to Pattern Matching

Thu, 29 Feb 2024 18:30:00 +0000

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:

Understand the basics of advanced pattern matching in Rust.
Apply these techniques to write cleaner, more efficient code.
Avoid common pitfalls and best practices to follow.

1. Basics of Pattern Matching

1.1 What is Pattern Matching?

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.

Getting Started with match:

Traits: Mastering Traits in Rust — Navigating Edge Cases and Best Practices (Part 3)

Thu, 29 Feb 2024 18:30:00 +0000

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.

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.

From Novice to Master: 10 Must-Try Low-Level Programming Projects in Rust

Wed, 28 Feb 2024 18:30:00 +0000

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.

1. Building a Guessing Game with a Twist

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.

Traits: Advanced Trait Concepts and Dynamic Dispatch in Rust (Part 2)

Wed, 28 Feb 2024 18:30:00 +0000

Trait Objects and Dynamic Dispatch

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.

Understanding Trait Objects and dyn Keyword

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.

Traits: Understanding Rust Traits - The Foundation (Part 1)

Wed, 28 Feb 2024 18:30:00 +0000

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!

Mastering Rust Lifetimes: The Comprehensive Guide

Fri, 23 Feb 2024 18:30:00 +0000

Mastering Rust Lifetimes: The Comprehensive Guide

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.

Part 1: The Foundations of Lifetimes

What Are Lifetimes?

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.

Rust Ultimate: The Ultimate Rust Cheatsheet You'll Ever Need

Tue, 20 Feb 2024 18:30:00 +0000

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.

Vector & LinkedList Operations

Rust’s Vec<T> and LinkedList<T> are versatile for handling collections. Here’s how to use them effectively: