CorrcodeModify

2026-07-21 08:00:00

We talked about patterns for defensive programming in Rust before, in which implicit invariants that aren’t enforced by the compiler lead to utter misery. But being careful isn’t enough! Even valid code can fail at runtime in ways that are hard to predict and control. That’s what we’re covering next.

Table of Contents

Panic Semantics Are Part of Your API

What happens when a Rust program panics? There is no single correct answer because panic! is not a “single behavior.”

Unwind vs. Abort

For starters, there’s a difference between unwind and abort.

catch_unwind invokes a closure, which captures the cause of an unwinding panic.

let result = panic::catch_unwind(|| {
    panic!("oh no!");
});

But the Rustonomicon has the following to say about unwinding panics:

We would encourage you to only do this sparingly. In particular, Rust’s current unwinding implementation is heavily optimized for the “doesn’t unwind” case. If a program doesn’t unwind, there should be no runtime cost for the program being ready to unwind.

The alternative to unwinding is aborting the entire process. That does what it says on the tin: the program immediately terminates without unwinding the stack or running destructors. Halt and catch fire. Weirdly enough, that’s often the safer choice, especially when dealing with FFI boundaries or performance-critical code. That’s because unwinding across FFI boundaries is undefined behavior, and unwinding can be expensive in performance-sensitive code.

To enable aborting on panic, add the following to your Cargo.toml:

[profile.release]
panic = "abort"

And even if you did not explicitly configure this, catastrophic panics like stack overflows and out-of-memory errors always abort the process. That’s because unwinding in these situations is unsafe and can lead to undefined behavior.

In practice, this shows up in two places:

• Panics that would unwind across an extern “C” boundary are defined to abort instead of unwinding, because letting unwinding cross that boundary is undefined behavior.
• And if a malloc fails, it aborts the process. If that’s a problem, you need to proactively check for allocation sizes before allocating or avoid heap allocations altogether.

These failures are fundamentally different from ordinary panics in that they cannot be caught or recovered from. To handle them gracefully, you need to know exactly how and where your program will run, and design accordingly. For example, in the case of malloc, avoid unbounded user input that could lead to excessive allocations.

Thread-Level vs. Process-Level Failures

Another difference is between thread-level failures and process-level crashes.

A common misunderstanding is that panic terminates the entire program, but in a multi-threaded application, that is not necessarily the case. For example, a background worker thread can panic while the main thread continues running. What sounds like a benefit can leave the system in a partially degraded state.

This distinction becomes especially important in long-running systems (servers, workers, async runtimes, …). A panic in a request-handling thread might only abort that one request, while the rest of the service remains available. Here’s a small example using scoped threads (Playground):

use std::{thread, time::Duration};

fn handle_request(id: u32) {
    println!("request {id}: started");

    if id == 2 {
        panic!("request {id}: handler panicked");
    }

    thread::sleep(Duration::from_millis(100));
    println!("request {id}: finished");
}

fn main() {
    thread::scope(|s| {
        let requests: Vec<_> = (1..=3)
            .map(|id| (id, s.spawn(move || handle_request(id))))
            .collect();

        for (id, request) in requests {
            match request.join() {
                Ok(()) => println!("main: request {id} completed"),
                Err(_) => println!("main: request {id} failed, but the process is still alive"),
            }
        }
    });

    println!("main: service keeps running");
}

The interesting part of the output is this:

request 1: finished
main: request 1 completed
main: request 2 failed, but the process is still alive
request 3: finished
main: request 3 completed
main: service keeps running

Request 2 panics, but requests 1 and 3 still finish. The panic belongs to the worker thread. The main thread gets notified on join() but keeps running. ¹

Whether this is acceptable depends on the system’s invariants. If a panic indicates a violated assumption confined to a small scope, like a single request, letting the process continue may be reasonable. But if it signals a global invariant violation, continuing execution can be outright dangerous.

Panic behavior is part of your system’s failure model. Treating all panics as equivalent hides important distinctions and leads to fragile assumptions. Be explicit about whether a failure may take down a single task, a single thread, or the entire process.

Never panic in an uncontrolled manner.

If you maintain a library, you have less control over where your code runs and what a panic can take down. Consider enabling stricter Clippy lints such as indexing_slicing and arithmetic_side_effects to catch common panic sources before they become part of your public API. Those lints can be noisy in applications, but they are often useful when panic freedom matters more than convenience.

Observing Failures With Panic Hooks

Now that you understand how panics work, let’s talk about operational hardening.

When things go wrong, you want to know about it. But by default, Rust panics just print to stderr and disappear into the void. In production systems, that’s not so great.

You might prefer crash reporting or centralized failure handling, and that’s where panic hooks come in. A panic hook is a function that gets called whenever a panic occurs, giving you a chance to record the failure before the program terminates or unwinds. It will not make an invalid state safe again. Its job is to capture enough context to debug the failure, alert someone, and shut down cleanly when possible.

Example Panic Hooks

Here’s a simple example of setting a panic hook:

use std::panic;

fn main() {
    panic::set_hook(Box::new(|panic_info| {
        eprintln!("Panic occurred: {panic_info}");
        // Log to your monitoring system
        // Send crash reports
        // Clean up resources
    }));

    panic!("Something went wrong!");
}

And here’s a panic hook that sends structured JSON data to a crash reporting service:

panic::set_hook(Box::new(|panic_info| {
    let panic_data = serde_json::json!({
        "message": panic_info.to_string(),
        "location": panic_info.location().map(|l| format!("{}:{}:{}", l.file(), l.line(), l.column())),
        "timestamp": chrono::Utc::now().to_rfc3339(),
        "version": env!("CARGO_PKG_VERSION"),
    });

    // Send to your crash reporting service
    crash_reporter::report(panic_data);
}));

And finally, here’s Sentry’s panic hook handler, which is even more sophisticated:

fn setup(&self, _cfg: &mut ClientOptions) {
    INIT.call_once(|| {
        let next = panic::take_hook();
        panic::set_hook(Box::new(move |info| {
            panic_handler(info);
            next(info);
        }));
    });
}

Sentry’s panic hook:

• Logs the panic information
• Preserves the previous panic hook behavior by calling next(info)
• Ensures the hook is only set once using INIT.call_once

There’s a lot to learn from these few lines of code!

Sanitizing Sensitive Data

Panic hooks are also your final opportunity to prevent information leaks. The sensitive data can come from two places: the panic payload and the panic location. The payload is whatever your code passed to panic!, unwrap, expect, or an assertion. That means it can contain interpolated user input, internal state from Debug output, request headers, tokens, email addresses, IP addresses, customer IDs, or other identifiers. The location can expose source file paths, workspace names, or CI/build machine directory layouts.

A well-designed panic hook sanitizes these messages before they reach logs or crash reports. Better yet, avoid putting secrets or raw user data into panic messages in the first place. Prefer stable error codes, request IDs, or redacted domain types. Regexes can catch obvious patterns like email addresses and bearer tokens. UUIDs and IP addresses can also identify users. Treat those checks as your final fallback.

panic::set_hook(Box::new(|panic_info| {
    let sanitized_message = sanitize_panic_message(panic_info.to_string());
    log::error!("Application panic: {sanitized_message}");
}));

You can look into crates like expunge or veil to automatically redact sensitive information from structs:

use veil::Redact;

#[derive(Redact)]
pub struct Customer {
    id: u64,

    #[redact(partial)]
    first_name: String,

    #[redact(partial)]
    last_name: String,

    #[redact]
    email: Option<String>,

    #[redact(fixed = 2)]
    age: u32,

    #[redact(with = "[REDACTED]")]
    address: String,
}

Cleanup Operations

Before the process terminates, you might want to flush logs, close network connections, or notify other systems that this instance is going down. Setting a hook is a great way to perform such cleanup operations.

Limitations

Panic hooks only run for unwinding panics. If your program aborts on panic, or if the panic is caused by a stack overflow or out-of-memory condition, your hook won’t execute.

Never rely on panic hooks for correctness.

They’re purely for observability and graceful degradation; don’t try to recover from logic errors as it is very hard to rely on a system’s fragile underpinnings at this stage.

Stack Overflows And Runtime Behavior

Okay, you handle errors gracefully and you know how your system behaves on panic. Panic behavior isn’t the only runtime failure mode you need to worry about.

Here’s some simple recursive code. What is wrong with it?

fn factorial(n: u64) -> u64 {
    if n == 0 {
        1
    } else {
        n * factorial(n - 1)
    }
}

The problem is that recursion can quickly exhaust stack space.

If you allow users to call this function with large inputs, it might crash your program. Rust does not guarantee tail-call optimization on stable Rust. Some compilers and languages can turn certain tail-recursive functions into loops, but you should not rely on that transformation in Rust. If recursion depth depends on user input or external data, rewrite the algorithm iteratively or put an explicit bound on the depth.

It takes some experience, but for recursive algorithms where you’re not in control of the input size, it’s often safer to use an iterative approach:

fn factorial(n: u64) -> u64 {
    let mut result = 1;
    for i in 1..=n {
        result *= i;
    }
    result
}

Release and Debug Builds Are Two Different Programs

One of the most dangerous assumptions in Rust development is that debug and release builds are functionally equivalent. They’re not. In many ways, you’re shipping a different program than the one you tested.

The most obvious difference is integer overflow behavior. Debug builds panic on overflow, while release builds silently wrap around. We covered that in Pitfalls of Safe Rust.

But the differences run deeper than arithmetic. Release builds remove debug_assert! checks, enable optimizations, and may exercise different code paths behind cfg(debug_assertions). Unsafe code and FFI boundaries are especially sensitive to this: undefined behavior can appear harmless in debug mode and break only once the optimizer starts relying on Rust’s aliasing and validity rules.

Here is a trivial example:

fn apply_discount(price: u32, percent: u32) -> u32 {
    debug_assert!(percent <= 100);
    price - (price * percent / 100)
}

In a debug build, apply_discount(100, 150) trips the debug_assert!. In a release build, the assertion is gone. The subtraction can underflow and wrap around, turning an invalid discount into a huge number. If the check protects a real runtime invariant, use assert! or return a Result instead of relying on debug_assert!.

Testing Release Behavior

The fact that tests pass in debug mode does not prove that production behavior is correct. Run normal debug tests as the fast default, and add release-mode tests for critical integration tests, arithmetic-heavy code, unsafe or FFI-heavy code, and anything whose behavior depends on optimization or release-only configuration.

# Add this to your CI pipeline alongside regular `cargo test`
cargo test --release

Supply-Chain Security

Your code is only as safe as your dependencies. You should regularly audit your dependencies for known vulnerabilities. Two helpful tools for that are cargo-audit and cargo-deny. It’s recommended to run those as part of CI.

Secure Allocations With mimalloc

mimalloc is a drop-in global allocator built by Microsoft. What’s special about it is that it also has a secure mode, which adds mitigations like guard pages, randomized allocation, and encrypted free lists to make some heap-corruption bugs harder to exploit. ²

Safe Rust already prevents most use-after-free and buffer-overflow bugs, and a secure allocator does not magically make memory-unsafe code safe. This is mostly defense-in-depth for programs with unsafe code, custom allocators, C/C++ dependencies, or FFI-heavy boundaries.

To enable secure mode, put this in Cargo.toml:

[dependencies]
mimalloc = { version = "0.1", features = ["secure"] }

Then use it as your global allocator:

use mimalloc::MiMalloc;

#[global_allocator]
static GLOBAL: MiMalloc = MiMalloc;

Now, all heap allocations in your Rust program will use mimalloc’s secure allocator. Measure the performance impact on your workload before rolling this out broadly; allocator choice can matter a lot for latency-sensitive services, games, packet processing, and other allocation-heavy programs.

Limit Your Runtime Attack Surface

Even well-written Rust code can be compromised through its dependencies, environment, or C FFI boundaries. The idea is to reduce your blast radius. Now, how you do that depends on your deployment environment, but generally people use Docker and Linux, so I thought I’d share some techniques for those; specifically, how to build minimal container images and filesystem sandboxing.

Minimal Docker images

A minimal production image contains exactly what you put in it. Even if your service is compromised, the attacker has very limited tools at their disposal to do further damage.

My recommendation is Google’s distroless images, but please do your own research³ as I’m not an expert on this.

Distroless images are minimal Debian-based images stripped of everything unnecessary, while still including TLS certificates and a non-root user. For a typical Rust web service, start with gcr.io/distroless/cc-debian13:nonroot: it includes the C runtime libraries that a normal Debian-built Rust binary may dynamically link against, but no shell or package manager. (Check the latest version in the distroless README.)

Here is an example Dockerfile using cargo-chef for dependency caching:

# syntax=docker/dockerfile:1

ARG RUST_VERSION=1.92

FROM rust:${RUST_VERSION}-bookworm AS chef
RUN cargo install cargo-chef --locked
WORKDIR /app

FROM chef AS planner
COPY . .
RUN cargo chef prepare --recipe-path recipe.json

FROM chef AS builder
COPY --from=planner /app/recipe.json recipe.json
RUN cargo chef cook --release --recipe-path recipe.json

COPY . .
RUN cargo build --locked --release --bin myapp

FROM gcr.io/distroless/cc-debian13:nonroot AS runtime
COPY --from=builder /app/target/release/myapp /bin/myapp
ENTRYPOINT ["/bin/myapp"]

Take this Dockerfile as a starting point, but please adapt it to your own project requirements.

cargo-chef keeps dependency builds in a separate Docker layer, so changing your application code does not force all dependencies to rebuild. The important details are: use the same Rust version in all build stages, build with --locked, scope workspace builds with --bin when appropriate, and keep target/, .git/, and editor files out of the build context via .dockerignore. For a deep dive on Docker images and build-time optimization, see Tips For Faster CI Builds.

Keep the Debian suffix explicit instead of using the unversioned tag, and pin by digest if reproducible deploys matter to you. If you deliberately build a fully static musl binary, then gcr.io/distroless/static-debian13:nonroot or even scratch can be a better fit. But don’t mix the two approaches: a glibc-linked binary needs a runtime image that provides the libraries it links against.

Filesystem sandboxing with Landlock

Even inside a minimal container, your process still has access to any file the container mounts. Landlock is a Linux security module that lets a process restrict its own filesystem access. If your service is ever exploited, the attacker can only reach the files you explicitly allowed. ⁴

use landlock::{
    Access, AccessFs, PathBeneath, PathFd, Ruleset, RulesetAttr,
    RulesetCreatedAttr, ABI,
};

fn sandbox() -> Result<(), Box<dyn std::error::Error>> {
    let abi = ABI::V3;

    Ruleset::default()
        .handle_access(AccessFs::from_read(abi))?
        .create()?
        // Allow read-only access to /etc for config files
        .add_rule(PathBeneath::new(PathFd::new("/etc")?, AccessFs::from_read(abi)))?
        // Allow read+write access to /var/data for your app's data
        .add_rule(PathBeneath::new(
            PathFd::new("/var/data")?,
            AccessFs::from_all(abi),
        ))?
        .restrict_self()?;

    Ok(())
}

fn main() {
    sandbox().expect("failed to apply landlock sandbox");

    // Your service starts here.
    // The service is now restricted to /etc (read) and /var/data (read/write)
    // Any attempt to open /tmp, /home, /proc etc. will be denied!
}

Call sandbox() as early as possible in main, before spawning threads or accepting connections. The restrictions apply to the entire process from that point forward.

The two approaches really go hand in hand:

• minimal images limit what’s in the container
• Landlock limits what the process can touch at runtime.

Drop Privileges and Capabilities

Don’t run as root in production, even inside a container. That’s one reason distroless images provide a nonroot user and why the example above uses the :nonroot tag. If your service only needs to listen for HTTP traffic, prefer a high port like 8080 over running as root just to bind to port 80.

Linux capabilities are another useful lever. Instead of giving a process full root privileges, grant only the specific capability it needs, such as CAP_NET_BIND_SERVICE for binding to low ports. If a process needs elevated privileges only during startup, drop them before accepting requests.

The details vary by platform and orchestrator, so treat Linux containers as one concrete setup. For systemd services, Kubernetes, FreeBSD jails, macOS sandboxing, or Windows services, look up the equivalent least-privilege and sandboxing features for that environment.

The big picture is that security hardening is about reducing the surface of things that can go wrong. Every capability your process holds unnecessarily is a liability and everything your code manages that could be delegated to the OS, init system, or container runtime probably should be.

Miri: Detect Unsafe Code Issues

Miri is an interpreter for Rust’s mid-level intermediate representation (MIR) that can detect undefined behavior at runtime.

It works by executing your Rust code in a special environment that tracks memory accesses, pointer validity, and other low-level details to catch issues that the compiler can’t statically guarantee against.

More people should know about Miri, because it is really helpful for hard-to-detect race conditions in multi-threaded or async code; but it can do way more than that, of course. It has already detected a lot of real-world bugs, even in the standard library.

Using it is as simple as running:

rustup +nightly component add miri
cargo +nightly miri test

This will run your tests under Miri’s interpreter.

The docs also describe how to add miri to CI:

  miri:
    name: "Miri"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Miri
        run: |
          rustup toolchain install nightly --component miri
          rustup override set nightly
          cargo miri setup
      - name: Test with Miri
        run: cargo miri test

(Make sure to check the latest instructions in the Miri repo, as the setup process may change over time.)

If you’d like to learn more about Miri, there is a research paper from 2026 that goes into the design and implementation details: Miri: Practical Undefined Behavior Detection for Rust.

Graceful Shutdown Handling

A hardened service doesn’t just crash. Instead, it shuts down gracefully when asked.

Aim to finish in-flight requests, flush your buffers, and release resources cleanly before you exit. The pattern is: listen for shutdown signals, stop accepting new work, drain existing work, then exit.

Frameworks like Axum have built-in support for graceful shutdown. Use it!

The key is handling signals like SIGTERM (sent by Kubernetes, systemd, or docker stop) and SIGINT (Ctrl+C). Here’s a minimal example using tokio-graceful-shutdown, which is a crate that provides good signal handling without much boilerplate. It introduces a concept of “subsystems” that can run concurrently and listen for shutdown requests.

use tokio_graceful_shutdown::{SubsystemHandle, Toplevel};

async fn subsys1(subsys: &mut SubsystemHandle) -> Result<()>
{
    log::info!("Subsystem1 started.");
    subsys.on_shutdown_requested().await;
    log::info!("Subsystem1 stopped.");
    Ok(())
}

#[tokio::main]
async fn main() -> Result<()> {
    Toplevel::new(async |s: &mut SubsystemHandle| {
        s.start(SubsystemBuilder::new("Subsys1", subsys1))
    })
    .catch_signals()
    .handle_shutdown_requests(Duration::from_millis(1000))
    .await
    .map_err(Into::into)
}

Circuit Breakers for External Dependencies

When an external service (database, API, cache) starts failing, you don’t want to keep hammering it with requests. A circuit breaker tracks failures and “trips” when a threshold is reached.

For production use, consider crates like failsafe or the more actively maintained recloser, which is based on failsafe.

Resource Limits

Unbounded resources are a common source of runtime failures. Everybody who was on call for a production service will tell you this.

Set explicit limits on everything. SREs will thank you for it! Limits make your service more predictable, and they make misconfigurations obvious sooner.

Common things you should limit include:

• Upper bound on any user input (upload file size, parameter bounds, etc.)
• request body size
• timeouts on external calls
• concurrent connections to external services
• queue depth for background jobs
• thread count and DB connection pool size

Here are some examples of how to do this in practice:

Request body size limits

See Axum’s DefaultBodyLimit:

let app = Router::new()
    .route("/", post(|request: Request| async {}))
    .layer(DefaultBodyLimit::max(1024));

Limit queue depth

Bound the number of items in every queue or channel in your system.

use tokio::sync::mpsc;
let (tx, rx) = mpsc::channel::<Job>(1000); // bounded channel, max 1000 pending

Set timeouts on everything external

let client = reqwest::Client::builder()
    .connect_timeout(Duration::from_secs(5))
    .timeout(Duration::from_secs(30))
    .build()?;

Every unbounded resource is a potential DoS vector. Explicit limits turn those catastrophic failures into (annoying but harmless) graceful rejections.

Health Checks and Self-Healing

Ideally, your system should be able to recover from transient failures without human intervention. Health checks let load balancers and orchestrators know when something is wrong, so they can react.

A typical setup has two endpoints, a liveness probe and a readiness probe. The liveness probe checks if the process is alive at all, while the readiness probe checks if the process is healthy enough to handle traffic.

This could honestly be an entire article on its own, but here’s a quick example using Axum to illustrate the concept:

use axum::{routing::get, Router, Json};
use serde::Serialize;

/// Status can be "healthy", "degraded", or "unhealthy"
#[derive(Serialize)]
enum Status {
    // Everything is good, all dependencies are healthy
    Healthy,
    // Some dependencies are degraded,
    // but the service can still handle requests
    Degraded,
    // Critical dependencies are down
    // Don't send any traffic
    Unhealthy,
}

/// This is our health status struct,
/// which we will return as JSON from
/// the readiness probe
#[derive(Serialize)]
struct HealthResponse {
    // Health status of the service
    status: Status,
    // Is the database connection healthy?
    database: bool,
    // Is the cache connection healthy?
    cache: bool,
    // What version of the service is running?
    // (Useful for debugging and monitoring.)
    version: &'static str,
}

// Liveness: "Is the process alive?"
// Should always return 200 if the server can respond at all
async fn liveness() -> &'static str {
    "OK"
}

// Readiness: "Can you handle traffic?"
// Check dependencies before saying yes
async fn readiness(
    db: Extension<DbPool>,
    cache: Extension<CachePool>,
) -> Json<HealthResponse> {
    let db_ok = db.ping().await.is_ok();
    let cache_ok = cache.ping().await.is_ok();

    let status = match (db_ok, cache_ok) {
        (true, true) => Status::Healthy,
        (false, false) => Status::Unhealthy,
        _ => Status::Degraded,
    };

    Json(HealthResponse {
        status,
        database: db_ok,
        cache: cache_ok,
        version: env!("CARGO_PKG_VERSION"),
    })
}

let app = Router::new()
    .route("/health/live", get(liveness))
    .route("/health/ready", get(readiness));

What’s neat about it is that this maps directly to Kubernetes’ health check system:

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Do we really need both probes? Yes, because they serve different purposes:

• Kubernetes stops sending traffic (graceful degradation) if the readiness probe fails. It does not yet kill the pod.
• Kubernetes restarts your pod if the liveness probe fails (it’s self-healing!)

Runtime Hardening Tooling

Finally, here are some more tools that help you catch problems before they hit production:

• cargo-fuzz – fuzz testing for Rust code
• honggfuzz – another fuzzer with Rust support
• cargo-geiger – detects usage of unsafe code
• cargo-valgrind – runs Valgrind on Rust code to find memory errors
• cargo-llvm-cov – code coverage via rustc/LLVM source-based instrumentation (-C instrument-coverage). It reports line and region coverage, works with cargo test and cargo nextest, and is a good default for new projects.
• cargo-tarpaulin – an older Rust coverage tool with strong Cargo and CI ergonomics. On Linux it defaults to a ptrace backend (x86_64 only); LLVM coverage is available through --engine llvm and is the default on macOS and Windows. Useful if its reports fit your workflow, but expect different platform and test-runner edge cases than cargo-llvm-cov.

The tools above help catch undefined behavior, memory safety issues, code coverage gaps, and performance bottlenecks. They are dynamic analysis tools that complement Rust’s static guarantees.

2026-07-17 08:00:00

In workshops I often see people getting frustrated with Rust.

Here’s some of the feedback I hear:

• “The borrow checker rules make it hard to write code that compiles.”
• “It’s overwhelming! The syntax is complex with too many symbols and operators. ¹”
• “It’s difficult to transition to Rust from .”
• “The code is not satisfying to read, it feels clunky and verbose.”

From these frustrations, people often conclude that Rust is not for them and quit.

But after programming in Rust for 10 years, I think that your coding style has the biggest impact on how your Rust code will look and feel.

People often say Rust’s syntax is ugly, but I’d argue the syntax is the least interesting thing about Rust. The semantics (the bits and pieces the language provides to express your ideas and how those bits combine to build interesting things) are much more important.

The “ugliness” is only skin-deep; Rust’s beauty lies underneath the surface! And with better semantics comes better syntax.

If you feel like you’re fighting the language, then there’s a chance that the language is speaking to you. It tries to push you into a healthier direction, but if you resist, it will patiently wait until you give in. The moment you start to listen to what Rust is trying to teach you, everything snaps into place; writing Rust feels effortless.

Better semantics unlock nicer syntax. That means, the more you lean into the core mechanics behind Rust (traits, pattern matching, expressions, composition over inheritance, etc.), the more you can build on these concepts to write code that is readable and extensible. The syntax takes a backseat. It gives way to semantics, which are much more important.

If you write Rust like you would write idiomatic code in another language, it will never feel right. You have to embrace how Rust wants you to structure your code. “You can write bad Java code in any language,” is a common saying, and I think it applies here as well.

Good Rust can tick all the boxes: it’s correct, readable, and maintainable. Heck, I’d say it’s pretty, too!

Parsing Things

Let’s consider a simple example: parsing an .env file in Rust. How hard can it be?

DB_HOST=localhost
DB_PORT=5432

API_KEY=my_api_key
LOG_FILE=app.log

The goal is to parse the above content from a file called .env and return a data structure that contains the key-value pairs. Child’s play.

I invite you to write your own version first. Or at least take a second to think about the problem.

Then we’ll refactor a deliberately clunky first attempt into more idiomatic Rust and use that process to extract a general approach: read the standard library, lean on inference and types, handle errors explicitly, and split the problem into smaller parts.

A Painful First Attempt

A Rust learner will sit down and attempt to parse the above file. They might come up with a solution like the one below, which is not too far from what I’ve seen recently.

use std::collections::HashMap;
use std::fs::File;
use std::io::Read;
use std::path::Path;

// Parse .env file into a HashMap
fn parse_config_file<'a>(path: &'a str) -> HashMap<String, String> {
    let p = Path::new(&path);
    let mut file = File::open(&p).unwrap();
    let mut bytes = Vec::new();
    file.read_to_end(&mut bytes).unwrap();

    let s = String::from_utf8_lossy(&bytes).to_string();

    let lines_with_refs: Vec<&'_ str> = s.split('\n').collect();

    let mut idx = 0;
    let mut cfg: HashMap<String, String> = HashMap::new();

    // Iter lines
    while idx < lines_with_refs.len() {
        // Get the line reference and trim it
        let lref = &lines_with_refs[idx];
        let mut l = *lref;
        l = l.trim();

        // Skip empty lines
        if l.len() == 0 {
            idx += 1;
            continue;
        }

        // Skip comments
        if l.chars().next() == Some('#') {
            idx += 1;
            continue;
        }

        // Actual string splitting and trimming
        let parts = l.split('=').collect::<Vec<&str>>();
        let k: &str = parts[0].trim();

        // Check if key is empty
        if k.len() > 0 {
            // We found a valid key. Insert into config
            let v: &str = parts[1].trim();
            cfg.insert(k.to_string(), v.to_string());
        } else {
            // This only happens if the line is malformed, so skip
            println!("Error in line {:?}", parts);
        }

        // Process next line
        idx += 1;
    }

    return cfg;
}

fn main() {
    // Parse a `.env` file in the current directory.
    let config = parse_config_file(".env");
    println!("{config:#?}");
}

The code carries all the hallmarks of a beginner Rust programmer, possibly with a C/C++ background.

• Littered with unwrap() calls
• Unnecessary mutability
• Manual indexing into arrays²
• Lifetime annotations
• Cryptic variable names
• Imperative coding style

Let’s be clear: there are many, many antipatterns in the above code, but the most important observation is that these antipatterns have nothing to do with Rust itself. They are bad coding practices in general.

The learner has not yet fully embraced the ergonomics Rust provides and might be skeptical about performance implications of higher-level abstractions.

We will get back to this code later, but note how Rust makes all of these problems painfully explicit. It looks painful, because it is: the abstractions are too low level for the problem at hand.

Refusal to rethink your coding style in light of Rust’s design principles not only makes your code harder to read; worse, it slows down your learning process.

Down the road, it also leads to business logic bugs in the code, because the compiler can’t help you catch them.

Let Go Of Old Bad Habits

So how can you do better?

The first step is to acknowledge that your existing code goes against Rust’s design principles. It’s a band-aid around outdated ideas from the past still haunting you and holding back your progress. Ugly Rust code is a symptom of old, bad habits.

Based on this realization, we can systematically improve the code. While we go through the refactoring, keep in mind that there is no single “right” way to improve the code, but that it all depends on the context and your goals.

There are a few techniques that can help you write better Rust, some of which we’ve discussed before:

• Think in expressions
• Immutability by default
• Lean into the typesystem
• Use iterator patterns
• Read the standard library documentation
• Use proper error handling
• Split up the problem into smaller parts

Even just applying these basic techniques, we can get our code into a much better shape.

Tip #1: Read the Standard Library Documentation

Many common patterns are beautifully handled by the standard library. It is absolutely worth your time to read the documentation and even its source code. For example, you will find that you can get rid of all of this boilerplate:

let p = Path::new(&path);
let mut file = File::open(&p).unwrap();
let mut bytes = Vec::new();
file.read_to_end(&mut bytes).unwrap();
let s = String::from_utf8_lossy(&bytes).to_string();

and instead just call read_to_string:

let s = std::fs::read_to_string(path).unwrap();

Tip #2: Use Type Inference

Rust is really good at inferring types. That’s why we don’t need to specify the type of our HashMap explicitly.

let mut cfg: HashMap<String, String> = HashMap::new(); 

becomes

let mut cfg = HashMap::new();

Tip #3: Lean Into the Typesystem

Manual string splitting is error-prone and very much discouraged. The reason is that strings are, in fact, really complicated! There is an outdated assumption that strings are just an array of bytes, but that assumption is ill-defined and dangerous. It is not true for all modern operating systems, including Windows, macOS, and Linux and you should stop thinking about strings that way.

Even in our simple example code from above, string splitting turns out to be a common source of bugs:

let lines_with_refs: Vec<&'a str> = s.split('\n').collect();

This line expects that lines are separated by \n. That’s not true on Windows, where lines are separated by \r\n.

The following line does the right thing on all platforms:

let lines = s.lines();

This returns an iterator over the lines of a string. Knowing that, we can instead iterate over each line:

for line in s.lines() {
    let line = line.trim();

    // ...
}

Note that we shadow line with line.trim(). That is a common practice in Rust and very useful to keep the code clean.

It means we don’t have to come up with a fancy new name for the trimmed line and we also don’t have to fall back to cryptic names like lref or l instead.

By reading the standard library documentation (see tip 1), we learn about some useful methods on strings. So instead of line.len() == 0, we write line.is_empty() now. And line.starts_with("#") is easier on the eye than checking with l.chars().next() == Some('#').

for line in s.lines() {
    let line = line.trim();
    if line.is_empty() || line.starts_with("#") {
        continue;
    }
    // ...
}

Next, let’s tackle this part:

let parts = l.split('=').collect::<Vec<&str>>();

let k: &str = parts[0].trim();
if k.len() > 0 {
    let v: &str = parts[1].trim();
    cfg.insert(k.to_string(), v.to_string());
} else {
    println!("Error in line {:?}", parts);
}

Note how we access parts[0] and parts[1] without checking if these are valid indices. The code only coincidentally works for well-formed inputs. We could add a check to make sure that parts has at least two elements:

if parts.len() >= 2 {
    let k: &str = parts[0].trim();
    if k.len() > 0 {
        let v: &str = parts[1].trim();
        // insert into config
    } else {
        // handle empty key
    }
} else {
    // handle line error
}

But that’s equally clunky and verbose. Fortunately, we don’t have to do any of that if we lean into the typesystem a little more and use pattern matching to destructure the result of split_once:

match line.split_once('=') {
    Some((k, v)) => {
        let k = k.trim();
        if k.is_empty() {
            println!("Error in line with empty key");
        } else {
            let v = v.trim();
            config.insert(k.to_string(), v.to_string());
        }
    }
    None => println!("Error in line: no '=' found"),
}

With that, we end up with an already greatly simplified (but equally performant!) version of the code:

use std::collections::HashMap;
use std::fs::read_to_string;

fn parse_config_file(path: &str) -> HashMap<String, String> {
    let s = read_to_string(path).unwrap();

    let mut config = HashMap::new();
    for line in s.lines() {
        let line = line.trim();

        if line.is_empty() || line.starts_with("#") {
            continue;
        }

        match line.split_once('=') {
            Some((k, v)) => {
                let k = k.trim();
                if k.is_empty() {
                    println!("Error in line with empty key");
                } else {
                    let v = v.trim();
                    config.insert(k.to_string(), v.to_string());
                }
            }
            None => println!("Error in line: no '=' found"),
        }
    }

    config
}

Much nicer. However, to truly embrace Rust, it always helps to take a step back and think about the root of the problem. This is where you can really grow as a programmer.

Tip #4: Don’t Gloss Over Error Handling

We left a few things on the table so far; one obvious one is error handling. How you want to handle invalid lines depends on the business logic, but let’s assume we want to immediately return an error if the file is malformed.

The function itself stays close to what we had; it just returns a Result now and uses ? to bubble up I/O errors:

use std::collections::HashMap;
use std::fs::read_to_string;

fn parse_config_file(path: &str) -> Result<HashMap<String, String>, ParseError> {
    let s = read_to_string(path)?;

    let mut config = HashMap::new();
    for line in s.lines() {
        let line = line.trim();

        if line.is_empty() || line.starts_with("#") {
            continue;
        }

        match line.split_once('=') {
            Some((k, v)) => {
                let k = k.trim();
                if k.is_empty() {
                    return Err(ParseError::InvalidLine(line.to_string()));
                } else {
                    let v = v.trim();
                    config.insert(k.to_string(), v.to_string());
                }
            }
            None => return Err(ParseError::InvalidLine(line.to_string())),
        }
    }

    Ok(config)
}

The supporting ParseError type is mostly mechanical. We implement Display and Error so it plays nicely with the rest of the error ecosystem, and a From<std::io::Error> so that the ? on read_to_string just works:

use std::fmt;
use std::error::Error;

#[derive(Debug)]
enum ParseError {
    InvalidLine(String),
    IoError(std::io::Error),
}

impl fmt::Display for ParseError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        match self {
            ParseError::InvalidLine(line) => write!(f, "Invalid line format: {line}"),
            ParseError::IoError(err) => write!(f, "I/O error: {err}"),
        }
    }
}

// An empty body is fine here; we lean on the default `source()`.
impl Error for ParseError {}

impl From<std::io::Error> for ParseError {
    fn from(err: std::io::Error) -> Self {
        ParseError::IoError(err)
    }
}

In real projects, I often reach for thiserror to remove most of that boilerplate without hiding the important part: which errors can happen. The same error type becomes:

use thiserror::Error;

#[derive(Debug, Error)]
enum ParseError {
    #[error("Invalid line format: {0}")]
    InvalidLine(String),
    #[error("I/O error: {0}")]
    IoError(#[from] std::io::Error),
}

Granted, our code has gotten quite a bit more verbose again. But in comparison to the original code, the verbosity has a purpose: it marks the various bits and pieces of our code that can go wrong. We have agency to decide how to handle these errors gracefully on the call site rather than silently ignoring them.

Some errors are harder to handle than others. For example, we can choose to skip invalid lines, or we could decide to return a collection of all the errors we encountered while parsing the file. This and more we can express in code now.

Tip #5: Break Up The Problem

The “meat” of the parser is the part that parses individual lines. This is still buried in the single parse_config_file function, which has quite a lot of responsibilities such as reading the file, iterating over lines, and parsing each line. That causes a bunch of problems. For one, we can’t test the line parsing logic in isolation.

Since parsing lines is such a core part of the business logic, let’s make sure it gets the attention it deserves. For starters, let’s move the line parsing logic into its own function.

fn parse_line(line: &str) -> Result<Option<(String, String)>, ParseError> {
    let line = line.trim();

    if line.is_empty() || line.starts_with("#") {
        return Ok(None);
    }

    match line.split_once('=') {
        Some((k, v)) => {
            let k = k.trim();
            if k.is_empty() {
                Err(ParseError::InvalidLine(line.to_string()))
            } else {
                let v = v.trim();
                Ok(Some((k.to_string(), v.to_string())))
            }
        }
        None => Err(ParseError::InvalidLine(line.to_string())),
    }
}

Don’t worry about the ugly function signature for now; we get back to that in a second. In fact, it is a tell-tale sign that we’re still not quite done yet.

In Rust, code that feels “stringy-typed” is usually a sign of a missing abstraction.

In our case, the Result<Option<(String, String)>> type indicates that we are trying to parse a line that may or may not contain a key-value pair, and that parsing can fail. That is a good start for thinking about our missing abstraction.

We need to represent a few different outcomes of parsing a line:

• An invalid line, represented by the Result
• An empty line
• A comment line
• Finally, a valid key-value pair

Most likely, you would ignore empty lines and comments in your parser, but it’s still a valid outcome of parsing a line. The key insight is that these outcomes are now much more visible and that we have a choice of how to handle these outcomes in our code (in comparison to ignoring them like we did before).

With that in mind, we can define a new enum to represent the different outcomes of parsing a line:

#[derive(Debug)]
enum ParsedLine {
    // This is a valid key-value pair
    KeyValue(KeyValue),
    // A comment line
    Comment(String),
    // An empty line
    Empty,
}

#[derive(Debug)]
struct KeyValue {
    key: String,
    value: String,
}

We’d use it like so:

fn parse_line(line: &str) -> Result<ParsedLine, ParseError> {
    let line = line.trim();

    if line.is_empty() {
        return Ok(ParsedLine::Empty);
    }

    if line.starts_with("#") {
        return Ok(ParsedLine::Comment(line.to_string()));
    }

    match line.split_once('=') {
        Some((k, v)) => {
            let k = k.trim();
            if k.is_empty() {
                Err(ParseError::InvalidLine(line.to_string()))
            } else {
                let v = v.trim();
                Ok(ParsedLine::KeyValue(KeyValue {
                    key: k.to_string(),
                    value: v.to_string(),
                }))
            }
        }
        None => Err(ParseError::InvalidLine(line.to_string())),
    }
}

We could even go one step further and express more of our invariants in the type system. For example, we can make use of the fact that parsing a key-value pair only depends on a single line.

Since parsing is a fallible operation, we can implement TryFrom for our KeyValue struct:

use std::convert::TryFrom;

impl TryFrom<&str> for KeyValue {
    type Error = ParseError;

    fn try_from(line: &str) -> Result<Self, Self::Error> {
        let line = line.trim();

        if line.is_empty() || line.starts_with("#") {
            return Err(ParseError::InvalidLine(line.to_string()));
        }

        match line.split_once('=') {
            Some((k, v)) => {
                let k = k.trim();
                if k.is_empty() {
                    Err(ParseError::InvalidLine(line.to_string()))
                } else {
                    let v = v.trim();
                    Ok(KeyValue {
                        key: k.to_string(),
                        value: v.to_string(),
                    })
                }
            }
            None => Err(ParseError::InvalidLine(line.to_string())),
        }
    }
}

A natural reaction is to say “this is way too much work for such a simple problem.” And yes, taken in isolation, we are heavily yakshaving here.

Think of it this way: we can now reason about all edge-cases in isolation and errors get handled much closer to the source of the problem. We turned our big ball of mud into a smaller thing that is easier to work with.

The entire Rust standard library is full of abstractions that build on top of each other to help solve bigger problems. I encourage you to embrace that mindset shift. Your code will be more maintainable and extensible.

Our parse_config_file function now becomes much simpler:

fn parse_config_file(path: &str) -> Result<HashMap<String, String>, ParseError> {
    let content = read_to_string(path)?;
    
    let mut config = HashMap::new();
    for line in content.lines() {
        match KeyValue::try_from(line) {
            Ok(kv) => { config.insert(kv.key, kv.value); },
            Err(ParseError::InvalidLine(_)) => continue, // Skip invalid lines
            Err(e) => return Err(e), // Fail on any other error
        }
    }
    
    Ok(config)
}

All we do is create a map of key-value pairs from some input.

Tip #6: Introduce Ergonomic Abstractions

At this stage we might as well convert parse_config_file into a proper struct. And while we’re at it, let’s lift the requirement of passing a file path to the parser and instead accept any type that implements BufRead. This keeps the parser focused on lines instead of bytes. Files, strings, network streams, and test fixtures can all be wrapped in a buffered reader. It makes testing much easier.

use std::collections::HashMap;
use std::convert::TryFrom;
use std::error::Error;
use std::fs::File;
use std::io::{BufRead, BufReader, Cursor};

// `ParseError` is unchanged: the enum plus its
// `Error`, `Display`, and `From<std::io::Error>` impls.
#[derive(Debug)]
enum ParseError {
    InvalidLine(String),
    IoError(std::io::Error),
}
// ...

#[derive(Debug, Clone)]
struct KeyValue {
    key: String,
    value: String,
}

// Same logic as the `TryFrom<&str>` impl above, but taking an owned
// `String` (that's what `BufRead::lines()` yields).
impl TryFrom<String> for KeyValue {
    type Error = ParseError;

    fn try_from(line: String) -> Result<Self, Self::Error> {
        // trim, skip empty/comment lines, then `split_once('=')`
        // ...
    }
}

/// A configuration struct that holds the parsed key-value pairs.
//
// A newtype wrapper around `HashMap<String, String>` so we can change the
// internal representation later without breaking `EnvConfig`'s public API.
#[derive(Debug)]
struct EnvConfig(HashMap<String, String>);

impl EnvConfig {
    // Methods like `new`, `insert`, `get`, `len`,...
}

struct EnvParser;

impl EnvParser {
    fn parse<R: BufRead>(reader: R) -> Result<EnvConfig, ParseError> {
        let mut config = EnvConfig::new(); 

        for line in reader.lines() {
            match line {
                Ok(line_str) => {
                    match KeyValue::try_from(line_str) {
                        Ok(kv) => config.insert(kv),
                        // Skip invalid lines...
                        Err(ParseError::InvalidLine(_)) => continue,
                        // ...but return other errors
                        Err(e) => return Err(e),
                    }
                }
                Err(e) => return Err(ParseError::IoError(e)),
            }
        }

        Ok(config)
    }
    
    // Examples of parsing from different sources
    fn parse_str(input: &str) -> Result<EnvConfig, ParseError> {
        Self::parse(Cursor::new(input))
    }
    
    fn parse_file(path: &str) -> Result<EnvConfig, ParseError> {
        let file = File::open(path)?;
        Self::parse(BufReader::new(file))
    }
}

Example usage:

fn main() -> Result<(), Box<dyn Error>> {
    let env_content = "
        DB_HOST=localhost
        DB_PORT=5432
        
        API_KEY=my_api_key
        LOG_FILE=app.log
    ";
    
    let config = EnvParser::parse_str(env_content)?;
    
    println!("Parsed config entries:");
    for (key, value) in &config.0 {
        println!("{} = {}", key, value);
    }
    
    Ok(())
}

Phew, that was a lot of code, but look how much more maintainable and extensible it is now! We could even go one step further and make the EnvParser struct implement Iterator so that you can iterate over the parsed key-value pairs, but let’s stop here.

What We Achieved

By just following a few key principles, we have transformed our initial parser into a more idiomatic Rust implementation. Now, every part has one clearly defined responsibility:

• KeyValue is responsible for parsing a single line
• EnvParser is responsible for parsing the entire input
• EnvConfig stores the parsed key-value pairs

Sorry that I had to drag you through all of that, but it’s much easier to show than to tell.

I skipped a few intermediate steps, but the idea is always the same: continuously look for wrinkles in the code and move more and more logic into the type system.

Did You Find All The Edge Cases?

Lastly, I’d like to come back to my initial question about edge cases.

Parsing environment files sounds simple on the surface, but that is absolutely not the case! If you haven’t already, I encourage you to write your own implementation of an environment file parser.

And once you’re done, answer the following question: How many of these cases do you handle in your own implementation?

• Empty lines should be skipped
• Comment lines starting with # should be skipped
• Leading and trailing whitespace in keys and values should be trimmed
• Empty keys like =value should be rejected
• Empty values like key= should be allowed (with empty string value)
• Lines without an equals sign should be rejected
• On Unix, key=value=more is valid and everything after the first = is part of the value
• Indented lines with leading whitespace should be parsed normally
• Duplicate keys should overwrite earlier ones with later values
• Quoted values like key="value" should not include the quotes in the value
• Escape sequences like key=value\nwith\nnewlines or key=value#notacomment need careful handling
• Line continuations with backslash for multi-line values are not handled right now
• The parser should handle non-ASCII Unicode content
• Files with invalid UTF-8 encoding errors should be handled gracefully

A correct parser would need to handle all these cases. Our improved implementation handles many of these cases, but not all. This just goes to show how easy it is to gloss over details.

Summary

Rust’s beauty is in its semantics and the core mechanics it provides: ownership, borrowing, pattern matching, traits, and so on. If you merely look at its (admittedly foreign) syntax, you overlook the real elegance of the language.

If there is anything that makes Rust “ugly”, it isn’t its syntax but the fact that it doesn’t hide the complexity underneath. Rust values explicitness and you have to deal with the harsh reality that computing is messy. Turns out our assumptions about a program’s execution are often wrong and our mental models are flawed.

Fortunately, we can encapsulate a lot of the complexity behind ergonomic abstractions; it just takes some effort! So don’t worry: once you start to confront your bad habits and look around for better abstractions, Rust stops being ugly.

2026-07-16 08:00:00

Most Rust developers use the language, compiler, package registry, and tooling every day without thinking too much about the organization that helps keep parts of that ecosystem funded and sustainable.

This episode is a re-introduction to the Rust Foundation: what it does, what it does not do, how it relates to the Rust Project, and why that distinction matters for teams using Rust professionally.

My guests are Rebecca Rumbul, Executive Director and CEO of the Rust Foundation, Lori Lorusso, Director of Outreach at the Rust Foundation, and David Wood, Principal Software Engineer at Arm, Compiler Team Co-Lead in the Rust Project, and a Rust Foundation board member. Together we talk about the practical side of ecosystem stewardship: infrastructure, security, interop, maintainer support, governance, corporate membership, open-source funding, and the pressure new technologies like AI put on language ecosystems.

Show Notes

About the Rust Foundation

The Rust Foundation is an independent non-profit organization supporting the success, sustainability, and positive impact of the Rust programming language. Its work includes funding and supporting ecosystem infrastructure, security and interoperability initiatives, maintainer support, project administration, community programs, events, and collaboration with member companies and donors.

The Foundation is separate from the Rust Project. The Rust Project governs the language, compiler, standard library, and technical direction through its own teams and decision-making processes. The Foundation provides organizational, financial, legal, and operational support around that work, without owning Rust’s technical roadmap.

About the Guests

Rebecca Rumbul is the Executive Director and CEO of the Rust Foundation. She leads the Foundation’s work on organizational strategy, member engagement, sustainability, and support for the broader Rust ecosystem.

Lori Lorusso is Director of Outreach at the Rust Foundation. Her work connects the Foundation with the Rust community, member organizations, trainers, contributors, and companies adopting Rust in production.

David Wood is a Principal Software Engineer at Arm, CE-SW Rust Team Lead, Compiler Team Co-Lead in the Rust Programming Language Project, and a board member of the Rust Foundation. In this episode, David adds the perspective of someone involved in Rust’s technical work as well as Foundation governance.

Links From The Episode

• Mozilla - The first home of the Rust language
• Python Steering Council - The governing body of the Python Project
• How to Write a C++ Language Extension Proposal - Bjarne Stroustrup, the inventor of C++, on why C++ needed a standards committee
• SCRC - The Safety-Critical Rust Consortium
• FLS - The Ferrocene Language Specification, a specification of the Rust language that is required for certain steps in the certification of Rust for safety-critical applications
• Foundation Membership Tiers - The different quantifiable benefits from Diamond to Silver and Associate Memberships
• Rust Commercial Network - A group of organisations that use Rust in production working together with the Rust Project
• Rust-C++ Interoperability Initiative - An initiative of the Rust Foundation to improve interoperability between Rust and C++
• Rust Embedded Working Group - An official working group of the Rust language to improve usability of the language in hardware-constrained environments
• An AI Security Engineer in Residence for the Rust Ecosystem - Describing the position of the security engineer made possible by funding from Alpha-Omega
• Rust Foundation Maintainers Fund - The Foundation’s fund to support Rust maintainers
• Rust Foundation Trusted Training - The Foundation’s accreditation program for Rust training providers

Official Links

• Rust Foundation Website
• Rust Foundation Media Room
• Rust Foundation on GitHub
• Rust Foundation on LinkedIn
• David Wood’s website

2026-07-02 08:00:00

Most Rust in Production stories are about scale and performance. This one is a story about low-cost phones and patchy mobile connections in Africa, where a student is learning maths over WhatsApp. The whole point is to support hundreds of thousands of students cheaply enough to run at government scale.

My guest is Dylan Brown, a Senior Engineering Manager at Rising Academies, and he comes at Rust from an angle of being the person who signs off on using Rust for a new project.

For Dylan, it’s about what Rust enables: lower compute costs, boring deployments, painless refactors, and code reviews that focus on business logic instead of null checks.

Show Notes

About Rising Academies

Rising Academies is an education company founded in Sierra Leone in 2014 during the Ebola crisis. It helps governments deliver better learning at scale, working with and through national public school systems. Across seven randomized controlled trials, students in Rising-supported schools have learned on average 2.4x faster each year than their peers. Today Rising supports more than 400,000 students across 1,400 public schools in West and East Africa. Its technology group builds WhatsApp-based tools designed for the realities of limited connectivity and low-cost devices, including Rori (a maths tutor) and Tari (a teacher assistant).

About Dylan Brown

Dylan Brown is a Senior Engineering Manager at Rising Academies, where he leads the development of educational tools deployed across several African countries. He has over a decade in software development and years of experience with conversational systems, from public-transport data in South Africa to a fintech company whose chatbots handled millions in transactions. He now focuses on building trustworthy, accessible technology for resource-constrained environments, and it was Dylan who led the decision to adopt Rust for a new part of Rising’s stack.

Links From The Episode

• Why I like Rust as an Engineering Leader - Dylan’s blog post about the project
• axum - The ergonomic, Tokio-based web framework powering the backend
• sqlx - The async, pure-Rust SQL toolkit with compile-time checked queries
• cargo-xtask - Instead of writing Python scripts for your project, you can just write Rust scripts
• pydantic - A Python package that forces you to care about types in Python, coincidentally partially written in Rust
• Postman - A graphical API client useful for writing end-to-end tests
• Bruno - An open-source alternative to Postman
• turn.io - A platform for building WhatsApp-based apps

Official Links

• Rising Academies Website
• Rising Academies Careers
• Dylan Brown’s Blog
• Dylan Brown on LinkedIn

2026-06-18 08:00:00

There’s a particular kind of pressure that comes with maintaining software at the very bottom of someone else’s stack. ClickHouse lives in exactly that spot: roughly 1.5 million lines of mostly C++ and tens of millions of tests every single day.

So what happens when you start introducing Rust into a codebase like that? Not as a rewrite, but linked into a C++ server with a CMake build process that has to be reproducible and FIPS compliant? In today’s episode, we get into the messy, interesting reality. We talk about the question of whether the hardest part is Rust the language or Rust the ecosystem.

My guests come at this from two very different angles. Alexey Milovidov is the creator of ClickHouse and its CTO. He started the project back in 2009 and has spent decades thinking about performance, correctness, and what it actually takes to build a production database. Austin Bonander is a Senior Software Engineer at ClickHouse and a renowned open-source maintainer of sqlx. He works on the official Rust client as well as other Rust-related tooling. Together we talk about where Rust fits inside a C++ monolith, what it would take for Rust to earn a rewrite of core components, supply-chain and compliance headaches, and whether Rust is heading for the same accumulation of regrets that every “trendy” language eventually accumulates.

Show Notes

About ClickHouse

ClickHouse is an open-source, column-oriented OLAP database management system built for real-time analytics over very large datasets. The first version was written in 2009, it went into production in 2012, and it was open-sourced in 2016. Today it’s roughly 1.5 million lines of mostly C++, exercised by tens of millions of automated tests per day and a heavy regime of sanitizers and linters. ClickHouse is known for its raw query performance, and it powers analytics workloads at companies all over the world, from observability and logging platforms to large-scale data warehouses.

About Alexey Milovidov

Alexey Milovidov is the creator of ClickHouse and the CTO of ClickHouse Inc. He started the project in 2009 while working at Yandex and has guided its evolution from an internal analytics tool into one of the most popular open-source databases in the world. He’s spent his career obsessing over performance, correctness, and the kind of low-level engineering discipline it takes to keep a database trustworthy at scale.

About Austin Bonander

Austin Bonander is a Senior Software Engineer at ClickHouse, where he works on the official Rust client as well as other Rust-related tooling. He is a long-time member of the Rust community and a maintainer of sqlx, the async, pure-Rust SQL toolkit. Through that work he has thought deeply about database protocols, API ergonomics, and the long-term maintenance burden of widely used open-source libraries.

Links From The Episode

• OLAP - A type of database used for analytics, not storing relational data
• sqlx - The async, pure-Rust SQL toolkit Austin maintains
• Official /r/rust “Who’s Hiring” thread for job-seekers and job-offerers - Where Austin found the Clickhouse job
• Clickhouse’s C++ & Rust Journey - Alexeys talk at P99 CONF 2025
• No-Panic Rust: A Nice Technique for Systems Programming - Using linker checks to guarantee no panic calls in Rust code
• delta-kernel-rs - A Rust implementation of the Delta Lake kernel, with a non-trivial dependency graph
• ring - BoringSSL crypto code packaged as a Rust crate
• H3 - Uber’s Geo Hashing using hexagons, currently used in ClickHouse
• H3O - The same H3 Geo Hashing algorithm implemented in Rust, with better performance
• stdx - An attempt at creating an extended standard library with commonly used crates
• Hyrum’s Law - With enough users, every observable behavior of your system will be depended on by somebody
• Corrosion - CMake integration for Rust, used to link Rust into a C++ build
• Cargo - Rust’s build system and package manager, not designed for multi-language monorepos
• CMake - The build system that dominates the ClickHouse server
• Poco - The C++ libraries used by the ClickHouse server, without HTTP/2 support
• hyper - A fast HTTP implementation for Rust

Official Links

• ClickHouse Website
• ClickHouse on GitHub
• clickhouse-rs - The Rust client for ClickHouse, supporting both its native TCP and HTTP interfaces
• Alexey Milovidov on GitHub
• Austin Bonander on GitHub

2026-06-12 08:00:00

Safe Rust eliminates all data races. What it does not do is prevent race conditions in the broader sense: deadlocks, livelocks, and logic bugs in your synchronization.

What’s the difference?

These two terms get used interchangeably all the time, even by experienced developers, so it’s worth writing down exactly what Rust promises and what it does not.

What Is a Data Race?

To quote the Rustonomicon:

Safe Rust guarantees an absence of data races, which are defined as:

• two or more threads concurrently accessing a location of memory
• one or more of them is a write
• one or more of them is unsynchronized

All three conditions have to hold at once. If every access is a read, there’s no data race. If the accesses are synchronized (say, behind a lock), there’s no data race. A data race is specifically unsynchronized concurrent access where at least one side writes.

This matters because a data race is Undefined Behavior! A data race does not mean you might read a “stale” value. It means the compiler is allowed to do anything like tear a write in half and reorder it.

And you can’t wave this away as a harmless race that happens to work out. As Raph Levien notes in With undefined behavior, anything is possible:

It used to be thought that data races could be classified into “benign” and dangerous categories, but research strongly suggests that the former category doesn’t exist.

In other words, every data race is a real bug! And because it’s Undefined Behavior, the symptom can show up far away from the cause and much later, in the form of a corrupted value, a crash, or a security hole that only appears under heavy load.

For example, here are two threads incrementing the same counter:

use std::thread;

fn main() {
    let mut counter = 0;

    thread::scope(|s| {
        for _ in 0..2 {
            s.spawn(|| {
                counter += 1; // unsynchronized write to shared memory
            });
        }
    });
}

In many languages, the equivalent compiles and runs, and two threads writing to counter at the same time can corrupt it. The result depends on timing, so the bug may not show up until the code runs under load.

In Rust, it doesn’t compile at all:

error[E0499]: cannot borrow `counter` as mutable more than once at a time
  --> ex1_data_race.rs:8:21
   |
 8 |             s.spawn(|| {
   |             -       ^^ `counter` was mutably borrowed here
   |                        in the previous iteration of the loop
 9 |                 counter += 1;
   |                 ------- borrows occur due to use of `counter` in closure

The borrow checker stops you before the program can exist. Two threads both want a mutable reference to counter, and Rust’s core rule is that you can never have two mutable references to the same data at the same time. The data race is impossible because the aliasing it requires is impossible.

This is the point the Nomicon makes:

Data races are prevented mostly through Rust’s ownership system alone: it’s impossible to alias a mutable reference, so it’s impossible to perform a data race.

How Rust Lets You Share State Safely

So how do you increment a counter from two threads correctly? You make the access synchronized, which removes the third condition from the data race definition. Wrap the value in a Mutex, which lets only one thread touch it at a time:

use std::sync::Mutex;
use std::thread;

fn main() {
    let counter = Mutex::new(0);

    thread::scope(|s| {
        for _ in 0..2 {
            s.spawn(|| {
                *counter.lock().unwrap() += 1;
            });
        }
    });

    println!("{}", counter.into_inner().unwrap());
}

This compiles, and it always prints 2.

The compiler enforces this through two marker traits, Send and Sync. Roughly: Send means a value can be moved to another thread, and Sync means it can be shared between threads by reference.

A plain i32 can’t be mutated through a shared reference, and a mutable reference can’t be copied across threads. To share and mutate it, you need a type that provides interior mutability while remaining thread-safe (Sync), which is exactly what Mutex<i32> does.

Try to share something that isn’t Sync, like an Rc<T> or a RefCell<T>, and you get a compile error.

(Here the threads can’t outlive counter, so they borrow it directly. If they needed to outlive the scope, say with thread::spawn, you’d wrap it in an Arc to share ownership: Arc<Mutex<T>> is the workhorse for that.)

That’s the whole idea. Rust pushes many concurrency-safety checks from runtime into the type system.

Race Conditions Are Still Possible

So far we’ve made data races impossible. But a data race is only one kind of concurrency bug. The broader category is a race condition: any bug where the result depends on the timing or interleaving of threads. Rust does not protect you from those.

In the following example, the code moves money out of a shared bank account. That sounds quite scary, but we make sure to lock the Mutex on every access, so there is no data race anywhere in it.

use std::sync::Mutex;
use std::thread;

fn main() {
    // A shared account with $100 in it
    let balance = Mutex::new(100);

    thread::scope(|s| {
        for _ in 0..2 {
            s.spawn(|| {
                // Is there enough money?
                let can_withdraw = *balance.lock().unwrap() >= 100;
                // ...

                // withdraw the money, with a fresh, separate lock.
                if can_withdraw {
                    *balance.lock().unwrap() -= 100;
                }
            });
        }
    });

    println!("final balance: {}", balance.into_inner().unwrap());
}

One possible output is:

final balance: -100

but the output varies per run.

Both threads locked the mutex and checked the balance before, so how is that final balance negative?

There’s a subtle issue: both threads correctly locked the mutex, but they released the lock before they acted on the result of the check. The threads didn’t hold the lock for the entire time. So both threads can check the balance interleaved, seeing $100 before either thread has actually executed the withdrawal, leading both to decide they are cleared to proceed. Then both went ahead and withdrew. The account went negative.

Every individual access was synchronized, so the borrow checker is perfectly happy. The bug is that the check and the act are two separate critical sections. Between them, the world can change. This is a race condition (specifically a TOCTOU, time-of-check-to-time-of-use bug), and no type system can catch it for you, because the correctness depends on what you intended the locking to mean.

Once you understand this, the fix is simply to make the check and the act one atomic operation, holding the lock across both:

let mut balance = balance.lock().unwrap();
if *balance >= 100 {
    *balance -= 100;
}

You might think that this code is identical to the original, but it’s not. lock() returns a MutexGuard, and here we keep it in the balance binding instead of dropping it right away. The lock stays held for as long as that guard is alive, which (like any other value in Rust) means until the end of its scope. So the check and the withdrawal now happen inside one critical section, and no other thread can squeeze in between them. When balance goes out of scope, its Drop implementation releases the lock automatically.

In the original code, each *balance.lock().unwrap() produced a temporary guard that was dropped immediately at the end of that statement, so the lock was released the instant each access finished, leaving a gap for a race condition.

The compiler can’t know which behavior you wanted. As the Nomicon puts it:

It is considered “safe” for Rust to get deadlocked or do something nonsensical with incorrect synchronization.

Deadlocks Also Compile Just Fine

If incorrect locking is “safe,” then so is locking that never finishes. The simplest example: lock the same mutex twice on one thread. Rust’s standard Mutex is not reentrant, so the second lock() waits for a guard that will never be released.

use std::sync::Mutex;

fn main() {
    let data = Mutex::new(0);

    let _first = data.lock().unwrap();
    println!("got the first lock");

    // std's Mutex is not reentrant: this second lock waits
    // forever for a guard that will never be dropped.
    let _second = data.lock().unwrap();
    println!("got the second lock"); // never reached
}

This compiles without a single warning. Running it:

got the first lock
[hangs forever]

It prints the first line and then waits indefinitely. The borrow checker has nothing to say, because nothing here is unsafe in the memory sense. A deadlocked program isn’t reading bad memory; it’s just not making progress.

Real deadlocks are usually subtler than this. The textbook version is two threads that grab two locks in opposite orders, each waiting on the lock the other holds. But the general problem is that liveness (the program keeps making progress) is not something Rust’s safety guarantees cover. Safety is about not doing the wrong thing; it says nothing about eventually doing the right thing.

Atomics Are Not a Magic Bullet Either

You might think the bank-account bug was really about Mutex: drop the lock, reach for lock-free atomics, and the problem goes away. It doesn’t. The check-then-act trap has nothing to do with locks. It’s about composing operations, and atomics compose just as badly.

Atomics are synchronized by definition, so each individual operation is data-race-free. But “each operation is atomic” is not the same as “my sequence of operations is atomic”, which is exactly the gap we just saw with the mutex.

Here four threads each do 100,000 increments, but the increment is split into a separate load and store:

use std::sync::atomic::{AtomicU64, Ordering};
use std::thread;

fn main() {
    let counter = AtomicU64::new(0);

    thread::scope(|s| {
        for _ in 0..4 {
            s.spawn(|| {
                for _ in 0..100_000 {
                    // Two independent atomic operations are not atomic together! 
                    let current = counter.load(Ordering::SeqCst);
                    counter.store(current + 1, Ordering::SeqCst);
                }
            });
        }
    });

    println!("expected: 400000");
    println!("got:      {}", counter.into_inner());
}

Two example runs with two different (wrong) answers:

expected: 400000
got:      305352

expected: 400000
got:      168582

Every load and every store was a properly synchronized atomic operation. No data race occurred. But two threads can both load the same value, both add one, and both store it back, and one of the increments vanishes. It’s the bank account again: the gap this time sits between two atomic operations instead of between two locked sections. This is a lost update, which is, once again, a race condition. ¹

Notice that we’re using SeqCst, the strongest memory ordering Rust provides. The bug still occurs because the problem isn’t memory ordering; it’s that the increment is split into two separate operations.

The fix is to collapse the two steps into a single indivisible operation. With a lock, that meant holding the guard across both. With atomics, it means a single read-modify-write operation, fetch_add, which does the load-add-store in one step:

counter.fetch_add(1, Ordering::SeqCst);

With that one change, the program prints 400000 every time.

This is the same check-then-act trap as the bank account, with no lock in sight; the problem was never about Mutex.

So What Does Rust Actually Guarantee?

Safe Rust eliminates data races by design. A program with a data race does not compile. It’s a stronger guarantee than what runtime detectors like Go’s -race or C/C++’s ThreadSanitizer give you, because those only catch races that actually execute during a test run.

Safe Rust does not prevent race conditions in general. Deadlocks, livelocks, lost updates, and check-then-act bugs all compile cleanly and can still produce wrong answers or hang.²

Geo-ant, writing up a comparison of common C++ bugs against Rust, sums up the whole distinction in one line:

Rust does prevent data races and on the other hand you can still deadlock all you want.

The reason this distinction matters, and not just pedantically, is that it tells you where to spend your attention. You can stop worrying about torn reads and forgotten locks corrupting memory; the compiler has that. What’s left is the hard part of concurrency: making sure your critical sections cover your invariants, that your lock ordering is consistent, and that your logical operations are as atomic as you think they are.

Rust holds an enormous amount for you, and what remains is the part that lives in your intent, which no type system can read.

If you want to go deeper on the concurrency side of this, read Rust Atomics and Locks by Mara Bos. It’s free online.