Rust’s Debugger Gap Is a Data-Display Problem Before It Is a Tool Problem

Rust’s first dedicated debugging survey points to a problem deeper than debugger choice. More than 2,300 people responded, yet over half said they do not currently use a debugger for Rust. Print debugging and the dbg! macro remain the default because they are often faster and easier to set up.

The strongest signal is about visibility. Slightly more than 74% of respondents identified poor representation of values as a debugger pain point, while more than 55% said they had been unable to print variables. The complaints were especially concentrated around enums and collections such as HashMap and Vec, where implementation details can obscure the state a developer actually needs.

Stepping is also unreliable in the cases where Rust programs become most conceptually complex. A little over 51% of respondents reported problems stepping through code. Among them, async code was the most common context, at slightly over 28%, followed by macro-heavy code at about 23%. Only one quarter of respondents said they use debuggers to debug async code, although the report cautions that this may reflect either weak tooling or limited use of async programs.

This makes the survey’s most useful angle architectural: improving Rust debugging may require a better data-presentation layer, not only more debugger integrations. The report proposes displaying enums through their actual variants, rendering collections as contents rather than internal layouts, and showing String and CString values as text. It also calls for better async stack traces, improved stepping through iterators and futures, and clearer setup documentation.

Rust already has a mechanism for part of this work. The debugger_visualizer attribute embeds Natvis files for Microsoft debuggers or GDB pretty-printer scripts into debug information. The Rust Reference documents that the attribute improves value display and can be applied to a module or crate root. Yet nearly 62% of respondents who identified as library authors said they were unaware of the attribute. Among the smaller group who knew about it but did not use it, time and lack of knowledge about writing visualizer scripts were major barriers.

For Rust infrastructure teams, the immediate lesson is practical: debugger usability should be tested against the values developers inspect, not just whether breakpoints and stack traces work. A canister, service, or systems component that mixes Rust with C, C++, or Python also needs a realistic cross-language debugging path; 44% of respondents said they debug programs combining Rust with another language, with C the most common companion.

The report does not announce a single fix or promise a release timeline. Instead, it turns a familiar complaint into a prioritized maintenance agenda: make values legible, make async execution traceable, and make visualizer support easier to create and keep working. These are survey results rather than a controlled benchmark of all Rust developers, and the report specifically notes that the subgroup of people who stopped using Rust was small. Even with that limitation, the findings give the project a concrete way to measure whether future tooling makes debugging faster than reaching for logs.