5 ms·
In my experience, the debugging story isn’t as bad as most think, because compilation times are so fast. If I need to run some code at a random location to see
by cle 7y ago
In my experience, the debugging story isn’t as bad as most think, because compilation times are so fast. If I need to run some code at a random location to see what’s going on, I just add it and rerun the unit test, usually it takes less time than configuring a debugger to do the same thing, and I’ve also now got a place to put a UT to cover whatever the problem was.
- tsimionescu 7y agoEdit-compile-rerun is as fast or slower in Go compared to Java, C#, Python, Ruby and many others, and it's still an option in those languages. Comparing to C, C++ or Rust, or, surprisingly, JS, instead, you're probably right. However, unit testing is not by any means a substitute for all uses of a debugger. You can add unit tests to reproduce an error in any language, but once your problems start crossing module boundaries, a debugger (or printf debugging at least) often becomes indispensable. And having an edit-and-continue debugger is extraordinarily helpful when dealing with bugs that only reproduce in complex application states (when your cycle becomes edit-compile-rerun-send50CommandsToPutAppInCorrectState-reproduce).