4 ms·

Most Go programmers I know use printf debugging, not GDB. It fits with the Go philosophy of doing everything from the code, minimizing tools and config files.

by oofabz 13y ago

Most Go programmers I know use printf debugging, not GDB. It fits with the Go philosophy of doing everything from the code, minimizing tools and config files. This is not because the tools are so bad we are forced to bang rocks together. It's because writing code is an effective way to diagnose bugs. Even when I'm in a full-blown IDE with a GUI debugger, I prefer to use printf debugging.

natural219 13y ago
I do too, I think this is more efficient when I understand what's going on. However, let's say I'm given a third party library, and I know essentially what it does. I want to "see" the properties and methods of the object, I want to "inspect" values, and I want to "test" expressions, all at once. If you're just using printf, then between each of those steps you need to write a line of code, recompile, and reach that state in your program again. Like I said, if you already know essentially what's going on, deep dives like this become less and less important. However, I just think it's a boneheaded philosophy for a language / toolchain to just like...I don't know, assume you're good. I'm trying to become good, but I am getting more and more frustrated with Go every time the default answer to my problem is "be less of an idiot"
- mercurial 13y ago
  It's not necessarily a matter of being good. Writing efficient code doesn't mean that you can build a mental model for a reasonably complex projects, which will naturally accumulate dependencies. If you're lucky, you'll get a mental model of the component you're working on, and some of the more problematic dependencies. That's where being able to dive into arbitrary code during execution becomes crucial. Especially if the problem occurs in a piece of code you don't have access to at the layer you operate, and hence can't display the value for easily, or at all.
Intermernet 13y ago
Yes, I usually rely on printf as the Go fmt library string formatting options are so powerful ("%#V" for instance). I have however found that sleep is the best debugger. Move away from the computer, visualize the problem in your head, and sleep on it. Not the best advice for those on tight release schedules, but true none the less. Sometimes, however, it's nice to be able to see a live flow of the program and to watch variables change as you step through. I think we'll see more powerful tooling for Go debugging coming through very soon. I'd love to see more integration in the various editors for go oracle, go cover tool etc. as these would probably show me when I started introducing errors, with the relevant info a click (or key combo) away, before they turned into horrible bugs requiring their own git branch to solve. TDD with the go cover tool is brilliant!
mononcqc 13y ago
Printf debugging and its equivalents is something that can be done in all languages. I use it in Erlang too from time to time in dev. What makes it win is how easy it is to use. What makes it lose is how tedious and manual it is. And how it is restricted to an environment where you are allowed to recompile and load code all the time, and where the output is not going to mess up any other data stream. I'm starting to phase out printf debugging in favor of tracing, because the tracing tools in Erlang are just infinitely better and more flexible, AND they can work on a production running system without impacting performance in any major way. I'm able to match specific functions, with specific argument sets. I can see what they returned, and match only specific processes or generations of processes. I can do it from a REPL (because there is one, even in production systems, without needing to run stuff in a screen session), without messing up any related output stream. Printf debugging is attractive because of how simple and minimally disruptive it is when you're already writing code. As much as it amazes me, it turned out not to be the most convenient tool available for most cases, even if I still use it from time to time.

by oofabz 13y ago

natural219 13y ago

I do too, I think this is more efficient when I understand what's going on. However, let's say I'm given a third party library, and I know essentially what it does. I want to "see" the properties and methods of the object, I want to "inspect" values, and I want to "test" expressions, all at once. If you're just using printf, then between each of those steps you need to write a line of code, recompile, and reach that state in your program again. Like I said, if you already know essentially what's going on, deep dives like this become less and less important. However, I just think it's a boneheaded philosophy for a language / toolchain to just like...I don't know, assume you're good. I'm trying to become good, but I am getting more and more frustrated with Go every time the default answer to my problem is "be less of an idiot"

mercurial 13y ago
It's not necessarily a matter of being good. Writing efficient code doesn't mean that you can build a mental model for a reasonably complex projects, which will naturally accumulate dependencies. If you're lucky, you'll get a mental model of the component you're working on, and some of the more problematic dependencies. That's where being able to dive into arbitrary code during execution becomes crucial. Especially if the problem occurs in a piece of code you don't have access to at the layer you operate, and hence can't display the value for easily, or at all.

Intermernet 13y ago

Yes, I usually rely on printf as the Go fmt library string formatting options are so powerful ("%#V" for instance). I have however found that sleep is the best debugger. Move away from the computer, visualize the problem in your head, and sleep on it. Not the best advice for those on tight release schedules, but true none the less. Sometimes, however, it's nice to be able to see a live flow of the program and to watch variables change as you step through. I think we'll see more powerful tooling for Go debugging coming through very soon. I'd love to see more integration in the various editors for go oracle, go cover tool etc. as these would probably show me when I started introducing errors, with the relevant info a click (or key combo) away, before they turned into horrible bugs requiring their own git branch to solve. TDD with the go cover tool is brilliant!

mononcqc 13y ago

Printf debugging and its equivalents is something that can be done in all languages. I use it in Erlang too from time to time in dev. What makes it win is how easy it is to use. What makes it lose is how tedious and manual it is. And how it is restricted to an environment where you are allowed to recompile and load code all the time, and where the output is not going to mess up any other data stream. I'm starting to phase out printf debugging in favor of tracing, because the tracing tools in Erlang are just infinitely better and more flexible, AND they can work on a production running system without impacting performance in any major way. I'm able to match specific functions, with specific argument sets. I can see what they returned, and match only specific processes or generations of processes. I can do it from a REPL (because there is one, even in production systems, without needing to run stuff in a screen session), without messing up any related output stream. Printf debugging is attractive because of how simple and minimally disruptive it is when you're already writing code. As much as it amazes me, it turned out not to be the most convenient tool available for most cases, even if I still use it from time to time.