4 ms·

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 wit

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. :)

jff 14y ago
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.
- trungonnews 14y ago
  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.
  - NateDad 14y ago
    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.
burntsushi 14y ago
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.
lobster_johnson 14y ago
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.

jff 14y ago

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.

trungonnews 14y ago
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.
- NateDad 14y ago
  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.

burntsushi 14y ago

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.

lobster_johnson 14y ago

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.