Hacker News Reader

Comment by gnulinux | Hacker News Reader

> In this thread it is revealed that all (almost all) Rust devs are printf() not breakpoint devs, and why.

I'm a non-proud printf() debugger. I understand that if I get use to debugger debugging it'd be in many ways better. The thing is, it's an entirely different paradigm of development, and paradigm shifts can come with significant productivity cost. Of course, learning, growing and getting comfortable with new/different tools is part of being a software engineer.

View on HN

Have you tried using a debugger at all? I see people who've resisted for years become mega fans when they finally try one.

I also see people who use them all the time but reluctantly - I'd love to know what the difference is.

Yes I used debuggers many many times, I'm also relatively experienced with e.g. gdb commands syntax etc. It doesn't seem to fit my workflow for various reasons. In very short, my development style is some form of extreme TDD: when I write code it's almost always of the form "write test, red, write code, still red, write code, green" loop. I know many people hate it but this is what I came to like over the many years and this is what makes me productive the most. I am working on adopting different development paradigms recently though.

That certainly makes sense - and that tight loop is very compelling.

What if you have to solve a bug outside of the development loop though? E.g. a bug somewhere in the whole system after you've done your development, where you don't have a root cause yet?

I write integration tests as well as unittests, but mostly integration tests, to a reasonable extent. I also don't commit all integration tests if it's impractical e.g. makes the test suite too slow, instead have equivalent unittests. I use integration test to understand the underlying bug, then write a unittest. But, truthfully, to understand where to begin with, I religiously use logs. Normally prod logs are disabled or silenced, so the first step of debugging is enabling logs, reproduce the error in prod, get logs. Then, I inspect the logs and develop a hypothesis where the bug is. I write an integration test reproducing the exact same bug, red, I fix the bug, green. Then, I decide whether I want to commit this test, is it useful, is it fast enough. If so, we're done. Otherwise, I undo my commit, I write a unittest, red, apply the previous fix as-is, green. As you see, this is a mix of printf() debugging (logs are essentially printf statements) and TDD. One problem with this approach is, of course, if your logs aren't sufficient you may not now where to start. Then, you need to either ssh into a dev env and play around, or recreate the infra on you laptop and use a debugger to step through. I make sure my logs and tests are excellent in order to prevent these scenarios though, I also make sure the system is idempotent so that it's easy to reproduce bugs (because leadership tends not to like verbose logging enabled in prod due to storage costs, this means before reproducing a bug you need enable logs).

I grew up on PHP (xdebug, var_dump, and stepping through the code) and C# with Visual Studio.

Compared to this gdb is just meh. I know, I know, Rust compiles to a nice binary, there's no runtime/vm/interpreter/JIT/intermediate-language/bytecode...

but that's not what I miss in gdb, I miss the discoverability, the visual representation, the whole I from the IDE concept.

Reply on news.ycombinator.com