Posted on

Ever stared at a 500-line error enum and wondered where it all went wrong? This week we're diving into error organization (because yes, there's actually a right way to do it). Plus, bzip2 goes full-Rust and the compiler team wants your performance feedback.

Let's jump in.

Deep Dive – Organizing Errors Without Losing Your Mind

Let's be honest, Rust's error system is powerful, but once your project gets big, it can turn into spaghetti. Two great writeups tackle this: Sabrina Jewson shares how to modularize errors in medium-sized codebases, and Sylvain Kerkour dives into managing errors across large, multi-crate systems.

The Problem

A single Error enum for everything starts out fine… until it bloats. You lose context, leak internal details, and tightly couple your modules. Suddenly, moving one module breaks everything.

Sabrina's Approach: Modular Errors

Keep errors local. Each module defines its own error enum. Only expose higher-level errors at public boundaries.

Why it works:

  • Keeps context specific
  • Avoids leaky abstractions
  • Encourages clean, reusable modules

Takeaway: Let your modules own their errors. It's like keeping tools in the right drawer.

Sylvain's Approach: Scalable Crate-Level Errors

For bigger systems, define per-crate errors and bubble them up with context using tools like snafu.

Why it works:

  • Maintains backtrace and call context
  • Keeps crate boundaries clean
  • Scales well with many moving parts

Takeaway: Wrap errors up the stack with context. Your future self debugging a production issue will thank you.

My 3 Key Takeaways:

  1. Start modular: Even small projects benefit from localized error types
  2. Scale with context: Use crates like snafu or thiserror to add clarity without boilerplate
  3. Errors are architecture: Clean error design helps you reason about your system as a whole

Got a project that's growing fast? This is the moment to invest in smart error handling—it'll save you hours later.

bzip2 Goes All-Rust

The bzip2 crate just dropped C and went full-Rust with version 0.6.0, thanks to the Trifecta Tech Foundation. Under the hood, it now defaults to libbz2-rs-sys—a pure Rust reimplementation. The old C version? Still there if you need it, but Rust is the new default.

Why This Rocks

  • Faster: Compression is ~10–15% quicker, decompression ~5–10%. Real, measurable gains
  • Cross-compilation friendly: No more dealing with C toolchains. WebAssembly, Android, Windows, it all just works
  • Clean & Safe: MIRI-compliant, symbol-safe, and audited by Radically Open Security

If your project depends on .bz2, this update gives you speed, simplicity, and less C-induced pain. It's a drop-in upgrade with real perks.

What I love here is how this project takes a crusty old C tool and gives it new life in Rust, without breaking things or adding complexity. It's a solid reminder that "rewrite in Rust" can actually work—especially when done with care.

Community Call – Rust Compiler Performance Survey 2025

Rust compile times still too slow for your taste? Now's your chance to help fix that. The Rust team just launched the 2025 Compiler Performance Survey, and they want your feedback on how rustc performs in the real world.

It's quick (about 10 minutes), totally anonymous, and open until July 7. Whether you're a daily cargo build warrior or just annoyed by slow incremental builds, your input will help shape future compiler improvements.

👉 Take the survey here

Let's help make Rust compile faster than your morning coffee brew.

Snippets


We are thrilled to have you as part of our growing community of Rust enthusiasts! If you found value in this newsletter, don't keep it to yourself — share it with your network and let's grow the Rust community together.

👉 Take Action Now:

  • Share: Forward this email to share this newsletter with your colleagues and friends.

  • Engage: Have thoughts or questions? Reply to this email.

  • Subscribe: Not a subscriber yet? Click here to never miss an update from Rust Trends.

Cheers, Bob Peters