Hacker News Reader

Comment by jff | Hacker News Reader

I debug it using Printfs as needed--it just doesn't need a ton of debugging, and Go makes it easy with the %#v format in Printf giving an appropriate, annotated representation of pretty much any data type. Stack traces are also very informative if something goes badly wrong.

I'm pretty sure GDB works now too, but again I have never really felt the need for it. But then, I've never really felt the need for syntax highlighting, code folding, or auto-completed function names. I feel like if my Go code has reached a level of complexity where it needs those things, I've done something wrong. My IDE is Acme, it lets me edit files, run my build scripts, and execute test programs.

View on HN

This sounds like me when I was still in college trying to hack out a 100 line of code for a small programming assignment... But this approach does not scale with a million line of code project. Anyone with real programming experience can tell you this. Corporates don't just shell out thousand of dollars for an IDE license for no reason. :)

Crap, there I was thinking developing Go for my employers was "real programming"! I guess I should go add a lot more boilerplate and un-needed complexity, maybe rewrite it in a true enterprise language like Java. Then it would be a big enough project to need an IDE, making it a "real" project.

Maybe I should just delete all these repos I've worked on for my job, the cluster management tool, the pedestrian simulator, the GSM radio emulator, the VM monitoring infrastructure, the distributed key-value store. They were written in Go, so I guess they weren't real programs.

Hey. If you can do all of that without requiring any assistance from a good IDE, then you have my respect. :)

However, I'm still sticking to my point. Debugging your code using Printf feels like 1990s.

You can always use gdb to debug. However, with type safety and proper unit tests (which are easy to write with Go's interfaces) you often don't need it.

I've been programming for over ten years and the only situation under which I need a debugger is when I'm working with a language that allows segmentation faults.

Maybe debuggers are useful to you in other scenarios, but they are by no means necessary. You don't need to be inflammatory about it.

Ad-hoc debug output does scale to large projects. I have not used an interactive debugger in about ten years.

My style is to only log when I'm debugging a failure I don't understand. Then I remove the log output.

I also make sure that my unit tests cover the problem case I was debugging, because problems that require this kind of detailed debugging tend to be the trickiest to keep maintained without regressions. And I try to make my code based on careful state management (or, if possible, statelessness), preferably with a state machine.

Reply on news.ycombinator.com