Rust survey finds most developers skip debuggers; print debugging dominates

February 2026 that drew more than 2,300 responses. Respondents skew experienced: 80% self-identified as intermediate or advanced Rust users. The headline result is simple: most Rust developers avoid debuggers and rely on print-style troubleshooting.

Print statements and the dbg! macro remain the dominant troubleshooting methods. 81% of respondents said logs and print statements are simply easier or faster than reaching for a debugger. That's not framed as laziness in the survey — it's a pragmatic response to tool failures.

Tooling split and basic debugger use

Among those who do use debuggers, LLDB inside an IDE is the most popular configuration overall. On Linux, the split between gdb on the command line and lldb in an IDE is essentially tied (gdb edges out lldb by less than half a percentage point). On Windows and macOS, IDE-integrated lldb leads by six points or more.

Async, macros, and cross-language pain

Async Rust is particularly hard to debug. Only 25% of respondents debug async code at all, and 28% of those who try report real problems doing it. Macros also cause trouble: 23% of respondents reported issues with macro-heavy code.

Mixed-language programs are common. 44% of respondents debug programs that combine Rust with other languages. Of that group, 70% pair Rust with C and 43% with C++. That means debugger workflows often need to cross FFI boundaries, where a Rust-only debugger view is insufficient.

A quieter survey finding: 62% of library authors said they'd never heard of the debugger_visualizer attribute, which lets crates define how debuggers should display their types. Among those who had heard of it but hadn't used it, lack of maintenance time and not knowing how to write the visualizer were common reasons. That points to an awareness and documentation problem as much as a tooling one.

The Rust team's published recommendations focus on concrete debugging improvements: better enum and collection display, rendering strings as readable text, improving async stack traces, and producing setup documentation so developers don't have to reverse-engineer debugger configuration. A Google Summer of Code project is working on debug info testing to catch regressions that erode trust in debuggers.

Mitch Ashley of The Futurum Group summarized the tradeoff plainly: Rust's compile-time guarantees have built enterprise credibility that its runtime tooling has not yet matched. When a debugger can't render values legibly, developers choose the tool that works.

If your team is adopting Rust for production infrastructure, include debugger value representation, async trace support, and cross-language debugging in your tool evaluation. Short-term fixes you can act on: adopt IDE setups with better LLDB support, add crate-level debugger visualizers where feasible, and document a reproducible local debugger configuration for your repo.