Rust debugging survey highlights value display and setup gaps

The Rust compiler team published its first debugging survey results on September 7, 2026, based on more than 2,300 responses. The findings describe respondents, not Rust developers as a whole.

Value display and setup deserve separate checks

According to the report, over 74% cited poor value representation. Over 81% said logs or print debugging were easier or faster when explaining why they skipped debuggers. Open responses also described setup friction.

An engineering team evaluating its debugging workflow should distinguish getting a session running from getting useful answers. A practical checklist would include inspecting an enum variant, reading collection contents and stepping through representative application code. Record setup steps separately from inspection failures: the former can inform onboarding documentation, while the latter gives tool maintainers a more specific problem to investigate. A successful debugger launch alone is a weak acceptance criterion.

Existing visualizers versus proposed improvements

The existing debugger_visualizer attribute supports Natvis files for Microsoft debuggers and Python pretty-printers for GDB. The team lists better value displays and async debugging as possible improvements, not shipped fixes; testing work under Google Summer of Code is ongoing.

For library authors, visualizers are worth evaluating against the debugger their users actually use, rather than treating them as a universal solution. Start with one difficult-to-inspect public type and decide who would maintain its display script. Teams should budget that maintenance explicitly and avoid making adoption plans depend on the survey’s proposed improvements: the report supplies priorities, not a delivery timeline.