Good debugger support is my #2 biggest wish for Rust. I’d love to be able to use gdb, but unfortunately even simple things are “broken”. For example, here’s a simple program that has a string and a struct and an enum containing a string:

#[derive(Debug)]
struct MyStruct {
    my_inner_string: String,
}

#[derive(Debug)]
enum MyEnum {
    Str(String),
}

fn main() {
    let s = "Hello, debugger!".to_string();
    let t = MyStruct { my_inner_string: s.clone() };
    let e = MyEnum::Str(s.clone());
    println!("{} {:?} {:?}", s, t, e);
}

A String in Rust is also a struct (pointer, length, capacity), but I can print it nicely in rust-gdb:

(gdb) print s
$1 = "Hello, debugger!"

However, when I print a struct or an enum containing a string, here’s what it looks like:

(gdb) print t
$2 = dbg::MyStruct {my_inner_string: alloc::string::String {vec: alloc::vec::Vec<u8, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: core::ptr::non_null::NonNull<u8> {pointer: 0x5555555a79f0}, _marker: core::marker::PhantomData<u8>}, cap: 16, alloc: alloc::alloc::Global}, len: 16}}}

$3 = dbg::MyEnum::Str(alloc::string::String {vec: alloc::vec::Vec<u8, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: core::ptr::non_null::NonNull<u8> {pointer: 0x5555555a7a10}, _marker: core::marker::PhantomData<u8>}, cap: 16, alloc: alloc::alloc::Global}, len: 16}})

Since most data in a real Rust program sits in structs and enums, the debugger experience is made almost useless because looking at data is really hard. I’m not sure also that rust-gdb can deal with async code (please teach me if it can).

And yet linux still doesn’t have a good UI for all these fancy options. :(

It’s interesting how a VM like python and its debugger pdb are still stuck with the most basic feature and are not even able to be good at them. Debugging async(io) code is a complete farce. In the meantime, native debugger dealing with process and CPU can go back in time, trace and deal with concurrency.

What happened? Are Python developer just not using debugger? Working with these “modern” language feel so backward in term of tooling.

Tracing breakpoints (or tracepoints). But what if breakpoints didn’t break? 🤔 Say no more, instead of stopping the execution, we can print a message to the output. And not just a simple string literal like “got here lol”; the message can contain expressions to calculate and embed values from the program, e.g. “iteration #{i}, current monster is {monster->name}”. Essentially, we’re injecting printf calls to random places in our program without rebuilding and restarting it. Neat, right?

This made me laugh out loud. Even if you think that print statements are better than debuggers, you should still use a debugger to manage your print statements!

More generally, this article is making me think about the different between low-skill/“easy” and high-skill/“hard” tools. Anybody who can program can add print statements, but you have to actively learn how to use a debugger well. Relatedly people always say “profile before you optimize” but profilers are high-skill tools, so most people can’t use it. The only widespread high-skill tool I can think of is git, which 1) is far, far more impactful than profilers or debuggers, and 2) forces the whole team to know it.