News for hackers. Stuff that matters.

A comment on Speeding up the Rust edit-build-run cycle. Parent comment

Re:Speeding up the Rust edit-build-run cycle by 0x457 on Thursday November 14, 2024 @03:12PM (#42140672)
To be fair, if your code is multithreaded and sensitive to pauses, it becomes harder to debug with a debugger.

Ultimately, if you have a good logging setup and kinda know where the issue is a quick log message could be faster than debugging if all you want to do is look a variable value.

[ Parent | on HN ]
Re:Speeding up the Rust edit-build-run cycle by pjmlp on Thursday November 14, 2024 @04:39PM (#42141510)
That is where OS tracing like DTrace and ETW come into play, which can then be loaded into a debugging session.
[ Parent | on HN ]
Re:Speeding up the Rust edit-build-run cycle by kaba0 on Friday November 15, 2024 @03:41AM (#42144999)
Logging can change timing issues though. There are too many cases where an added log statement "fixed" a race condition, simply by altering the timing/adding some form of synchronization inherent in the logging library.
[ Parent | on HN ]
Re:Speeding up the Rust edit-build-run cycle by hibbelig on Friday November 15, 2024 @07:57AM (#42146489)
That’s true but boy howdy does pausing the program at a breakpoint change timing!
[ Parent | on HN ]