Most Rust developers don’t use a debugger. That’s the headline finding from the Rust compiler team’s first dedicated debugging survey, and it’s worth sitting with for a second. Rust has spent years building a reputation as the language that catches your mistakes before you ship them. The compiler is famously strict. The type system is famously thorough. And yet, when something goes wrong at runtime, most developers reach for a print statement instead of a debugger.
The survey ran in February 2026 and pulled in more than 2,300 responses from a developer base that skews experienced — 80% of respondents identified as advanced or intermediate Rust users. Only 46% currently use a debugger for Rust work. Print debugging and the dbg! macro remain the most widespread troubleshooting method by a wide margin, and 81% of respondents said logs and print statements are simply easier or faster than reaching for a real debugger.
That’s not developers being lazy. It’s developers being rational. When 74% report poor representation of values in the debugger and 55% say they can’t reliably print a variable at all, print debugging isn’t a shortcut — it’s the tool that actually works. Enums and collections took the brunt of the complaints, with HashMap and Vec singled out as particularly hard to read in a debugger session. A string type that shows up as raw memory instead of readable text doesn’t inspire confidence, and it sends developers straight back to println!.
Among the minority who do use a debugger, the tooling split tells its own story. lldb running inside an IDE was the most popular real debugger overall. On Linux, gdb on the command line narrowly edged out lldb in IDE, by less than half a percentage point. On Windows and macOS, IDE-integrated lldb won by six points or more. Once developers are in a debugger, 87% say they’re stepping line by line through code, and just over half use it to pull a stack trace from a crashed or hung process — the two most basic use cases there are.
Async code is where things fall apart. Only 25% of respondents debug async code at all, the lowest adoption rate of any use case in the survey, and 28% of the developers who try report real problems doing it. That tracks with what platform teams building async-heavy Rust services already know anecdotally: stepping through a future or an executor doesn’t look anything like stepping through a straight line of synchronous code, and today’s tooling wasn’t built with that mental model in mind. Macro-heavy code caused problems for 23% of respondents, which matters given how much idiomatic Rust leans on macros for everything from serialization to error handling.
Rust doesn’t live in isolation for most of these teams, either. 44% of respondents debug programs that mix Rust with other languages, and 70% of that group are pairing it with C, with C++ close behind at 43%. That matters for any organization running Rust inside a larger polyglot stack, which describes many enterprise infrastructure teams right now. A debugger that only understands Rust cleanly isn’t solving the whole problem for a team stepping across an FFI boundary into C.
There’s also a quieter finding buried in the results: 62% of library authors said they’d never heard of the debugger_visualizer attribute, a feature that lets a crate ship its own instructions for how a debugger should display its types. Of the smaller group who knew about it but hadn’t used it, about half cited a lack of maintenance time, and close to half didn’t know how to write the script in the first place. That’s an awareness gap as much as a tooling gap—the kind fixed with documentation, not a compiler release.
“Rust’s compile-time guarantees bought it enterprise credibility its runtime tooling has not earned. When a debugger cannot render a value legibly, print statements are the correct engineering call, and that call has hardened into culture,” said Mitch Ashley, Vice President and Practice Lead for CIO & Technology Buyers and for Software Lifecycle Engineering at The Futurum Group. “Platform teams standardizing on Rust for production infrastructure are inheriting verification debt they did not price. Value representation and async traces belong in the selection criteria alongside memory safety, and the people signing that standard have to say so.”
The Rust team already has a response in motion. Their published recommendations focus on fixing enum and collection representation first, rendering strings as text instead of memory dumps, improving async stack traces, and writing setup documentation so developers don’t have to reverse-engineer their debugger configuration. An ongoing Google Summer of Code project is targeting debug info testing, aiming to catch the kind of silent regressions that erode trust in a debugger over time. A newer community debugger called BugStalker is already experimenting with Rust’s own Debug trait to render values, which could sidestep many representation problems at once.
None of this is really about debuggers. It’s about whether Rust’s tooling can keep pace with where the language is being deployed — increasingly in production infrastructure where a 2 a.m. debugging session isn’t optional. A language built on catching errors at compile time still needs good answers for the errors that only show up at runtime. Right now, print statements are filling that gap. This survey is the first real evidence of how big it is.