# Rust debugging survey highlights value display and setup gaps > Rust’s first debugging survey highlights value-inspection problems and setup friction, suggesting separate checks for onboarding and debugger usefulness. Canonical URL: https://www.devobs.io/news/news-2026-09-07-rust-debugging-survey-results/ By: Lena Fischer Published: 2026-09-07T14:33:20.475Z Updated: 2026-09-07T14:33:20.475Z Event date: 2026-09-07 Section: Languages The Rust compiler team published its first [debugging survey results](https://blog.rust-lang.org/2026/09/07/rust-debugging-survey-2026-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. ## Source references -