Let’s dive in!

Rust for C Programmers

As someone who came into Rust with a C background already under my belt, I found Rust for C Programmers to be a neat project, well thought out and refreshingly to-the-point. It’s a resource that respects your experience, trims the fat, and walks you through Rust’s more mind-bending features without over-explaining the obvious.

You can read it online at Rust for C programmers, and it’s entirely free.

What sparked my interest wasn’t just the book itself, but also a recent Reddit thread that brought it back into the spotlight. Folks over at /r/rust had a good mix of appreciation and critique. Some praised the clean structure and practical focus, while others wished it were a bit shorter or included async and macro chapters (which are apparently in the works). It was clear from the comments that the book fills a very real need: bridging the mental model of C with the safety and modern features of Rust.

The book itself is around 500 pages, but it reads faster than you’d think. It skips hand-holding and dives straight into how Rust approaches memory, ownership, and lifetimes differently. What I liked most is that it doesn’t try to be an exhaustive Rust encyclopedia. It knows its audience. It skips compiler internals and focuses on what actually matters when you’re coming from a background of malloc, pointers, and structs.

If you’re already comfortable with systems-level thinking and want a Rust book that talks your language, this is worth a read. Whether you’re just testing the waters or sharpening your understanding, it hits a nice balance of technical depth and straight talk.

Faster Linking for Rust: David Lattimore’s Mission to Make Compilation Snappy Again

What if your Rust builds finished before you stood up to get coffee?

That’s the vision David Lattimore is chasing. On a self-imposed sabbatical, he’s doing something most developers wouldn’t dare: writing a new Linux linker from scratch, tailored for performance, especially during development cycles. It’s called Wild, and it might just change how fast Rust compiles feel for all of us.

In a compelling podcast episode, David walks through the technical motivations behind Wild, how linking really works, and why it remains such a huge bottleneck for Rust builds, especially at the end of a long dependency chain. Meanwhile, the Reddit thread highlights just how excited the community is to finally see an alternative that puts developer speed first.

Why Wild matters

David started Wild in late 2023, and is still going strong, aiming for three things:

• Speed: Link times are often the slowest part of the Rust build process. Wild is explicitly built for low-latency, parallelized linking.
• Compatibility: It works today with Clang and supports most real-world linker flags.
• Incrementality: Although not yet implemented, it’s part of the long-term vision to make linking more dynamic and modular.

Despite being early-stage, Wild is already usable. David has been dogfooding it for six months on his own Rust projects. And even better: it’s open source and welcoming contributors.

Technical Deep Dives

The episode also peels back the curtain on:

• What a linker actually does (hint: it’s not just fusing binaries).
• Why debug info bloats memory usage.
• The intricacies of cross-compilation and relocations.
• When to return Result vs. panic! in systems code.
• How linker flag complexity evolved over decades (and why David ignores most of them unless they’re used in the wild, pun intended).

One of the most fascinating takeaways: Rust and its ecosystem still rely heavily on C/C++ toolchains at the linking stage. Wild aims to bring some Rust-native speed and modularity to that last mile of compilation.

Takeaways

• Wild is real: And already usable if you’re on Linux and can configure your toolchain to use Clang.
• Linking is still a black box for most developers — but it doesn’t have to be.
• Rust enables fearless, multithreaded systems programming — Wild’s architecture is a showcase for what Rust makes possible.
• There’s room to contribute: If you want to help, Wild’s repo is open, and David welcomes contributors.

“I want to regain that feeling of spontaneity and instantaneousness in a compiled language like Rust.”

— David Lattimore

If you’ve ever waited on a slow cargo build, Wild might be the breath of fresh air you didn’t know you needed. Keep an eye on it and maybe even contribute.

FireDBG, Rust Debugging, but with a Rewind Button

I came across a project recently that’s worth your radar: FireDBG, a time-travel visual debugger made specifically for Rust, by the folks over at SeaQL. The idea behind it is simple but powerful—debug your program like it’s a movie. Step forward, step backward, pause, rewind, and see exactly how things played out, all in a structured visual call tree.

What caught my attention is how it tries to solve a real pain point in debugging Rust: context. Not just what went wrong, but how your program got there. FireDBG records execution into a .firedbg.ss file that you can load in Visual Studio Code with their extension. It lets you explore function calls, variable states, and thread activity across the full timeline of a run. And yes, you can go backwards.

There’s also a CLI version if you’re not into visual tools, but the VS Code integration seems to be where the main experience is built. They even provide a testbench repo to help you try it out without wiring up your own project first.

The GitHub repo shows they’ve put serious thought into it, plenty of documentation, a clean design, and an emphasis on usability. There’s also been some chatter on <a href="https://www.reddit.com/r/rust/comments/18fz013/introducing_firedbg_a_time_travel_visual_debugger/" target=_"blank">/r/rust that echoes the same sentiment: this isn’t just a clever demo. It’s a real attempt at giving Rust developers modern debugging tools.

Even if you’re not jumping to use it today, it’s the kind of project that pushes Rust tooling in the right direction. Definitely something to keep an eye on, especially if your current debugging strategy still involves a lot of println!.

Snippets

• How we wrap external C and C++ libraries in Rust
• Designing Error Types in Rust Libraries
• 2,000x faster route propagation by rewriting our Traefik gateway in Rust

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