Rust Survey: Most Developers Favor println! as Debuggers Struggle to Show Values Like HashMap and Vec

Print statements are the rational choice given the tools on offer, the survey suggests. The devops.com write-up on the survey puts the mechanism plainly: a string type that renders as raw memory instead of readable text sends developers straight back to `println!` ^[11]. When 55% of respondents say they cannot reliably print a variable in a debugger session ^[9], print is the thing that returns an answer.

The survey argues with itself on one point. 81% said logs and print statements are simply easier or faster than reaching for a real debugger ^[7]. On its own that is a preference finding, the kind you get when a workflow has just become habit. Sat next to the 55%, it is a description of a tool that does not repay the time it takes to attach. The data cannot settle which weighs more, and a team funding tooling work should say out loud which reading it is betting on.

Depth of use is thin among the people who do attach. 87% of debugger users step line by line, and a little over half use it to pull a stack trace out of a crashed or hung process ^[15][16], which are the two cheapest things a debugger does. lldb inside an IDE was the most popular option overall ^[12]; on Linux, gdb at the command line beat it by less than half a percentage point ^[13], while on Windows and macOS the IDE-integrated lldb led by six points or more ^[14].

44% of respondents debug programs that mix Rust with other languages, and 70% of that group pair it with C, with C++ at 43% ^[22][23]. Multiply the first two and roughly 31% of the whole sample is stepping across an FFI boundary into C ^[24], where a debugger that only understands Rust cleanly solves half the problem. On the async side, 25% debug async code at all and 28% of those who try report real problems ^[17][18], which works out to about 7% of all respondents who have both attempted it and hit trouble ^[19]. That small number matters less than the much larger population that stopped attempting async debugging in the first place. Macro-heavy code tripped up 23% ^[21].

The fix for illegible values is already specified. The `debugger_visualizer` attribute lets a crate ship its own instructions for how a debugger should display its types ^[26], and among library authors who knew about it but had not used it, about half cited a lack of maintenance time while close to half did not know how to write the script ^[27]. Mitch Ashley, Vice President and Practice Lead for CIO & Technology, told devops.com that when a debugger cannot render a value legibly, print statements are the correct engineering call, "and that call has hardened into culture" ^[28]. The survey reports no measure of time to resolution or production incident outcomes ^[31], so 46% describes tooling experience, not how long anyone's last outage ran.

One useful way to sort the problem: put the value you cannot see on one axis, owned by your code or owned by a dependency, and the failure site on the other, synchronous or async and FFI. Your own types in synchronous code sit in the cheap cell, where a visualizer written once fixes it for everyone who touches the crate. A dependency's types in synchronous code call for a pull request upstream or a local wrapper type, worth pricing against another quarter of log plumbing. In async, your code is where tracing spans beat step-through, while a dependency's types in async land in the cell where step-through debugging is not currently the product you want to buy. Across all four, the share of your team that opens a debugger tracks what the crates in your dependency graph ship, more than it tracks discipline.