6 ms·

Debugging Go code (a status report)

28 points by abraham 16y ago

enneff 16y ago
How many people use debuggers like GDB day-to-day? I've found them useful when trapped in a corner, but typically I debug with the source in hand. Anyone got any good debugging war stories?
- abhijitr 16y ago
  I would assert that it is pure folly to attempt to build a non-trivial application in a compiled language without the assistance of a competent debugger. You simply cannot iterate quickly enough through the debugging loop of "Form theory" -> "Test theory" if you have to wait a minute for a build to complete each time. Unit tests help, but will never get you all the way there (good luck tracking down a leak with unit tests).
  - nickik 16y ago
    the repl is your friend even in compiled languages like haskell.
    - Devilboy 16y ago
      A proper REPL can do a lot of the same stuff you'd use a debugger for, and a whole lot more. With a nice REPL you'll do just fine without a debugger.
      - arethuza 16y ago
        Why not use a REPL and a good debugger? It's a nice combination.
  - enneff 16y ago
    I consider myself a "competent debugger". ;-) But more seriously: one of Go's selling points is fast compilation times. Even for large projects compilation is mostly I/O bound, which typically means sub-second compiles.
- konad 16y ago
  The Plan9 debugger, ACID is awesome, even in Unix. http://swtch.com/plan9port/man/man1/acid.html http://swtch.com/plan9port/man/man1/acid.html You can debug a kernel on a remote machine with a different architecture. Shame that we've got to go back to the dark ages of GDB for Go.
  - enneff 16y ago
    We have plans to build a more fully-featured, Go-centric compiler (and there's the beginnings of one in the source tree under pkg/exp/ogle), but we haven't had the time to get stuck into it yet.
hartror 16y ago
When it comes to debugging, nothing beats a few strategic print statements to inspect variables or a well-placed panic to obtain a stack trace. I respectfully disagree with this statement. Beyond simple issues a debugger is invaluable for following program flow and inspecting variable/memory states. And why does "missing .. patience" mean you are more likely to use a debugger over a print statement?
- supersillyus 16y ago
  In the last decade, I think I've pulled out a debugger only a handful of times. Apparently many people use them, but for me, understanding my code, writing tests, and tossing in some printfs has always been the way. I don't have a problem with debuggers, butfor me it is usually about having theories and testing them. This testing can happen in a debugger or in a print statement or in a test, but a test always seems like the best idea, and a print statement usually seems more straightforward to me than trying to stop and inspect my program while it is running.
  - itsnotvalid 16y ago
    Most of the time, for me, debuggers are only used on assembly code, which it is not as easy to insert a print statement or a hook.
  - barrkel 16y ago
    You use this "my" word a lot. I personally use debuggers for debugging other people's code, code that's possibly decades old, that doesn't have enough modularity for good unit tests, and whose bugs in any case often only show up in complex multithreaded integration scenarios. GDB only acquired multiprocessing debugging support this year; to my mind it's pretty primitive.
akeefer 16y ago
One of the first things you will find out, if you attempt to write a new programming language and then use it for actual production work, is how much users of that language will miss simple, taken-for-granted things like debuggers. Creating a programming language by itself isn't all that hard. The real work is actually making it usable with good error messages and stack traces, tools like debuggers and profilers, editor support (if you're into that sort of thing), and documentation and specs. All of that (especially good editor support) is easily an order of magnitude more work than a parser and a compiler, and that doesn't even consider libraries you might need to write if you can't interoperate with an established language. (Spoken from personal experience, for what it's worth).
- nickik 16y ago
  but the real hard thing is to make a language people want to use. If you did that the rest will be done by the comunity but even then it a lot of work. One of there reasons new langauges are often targeting the JVM or the CLR. You can reuse most of the tools and libs with less work.
  - akeefer 16y ago
    Exactly. Funny story there . . . we started our JVM language as interpreted, more or less, and ended up having to write our own not-so-great debugger for it. We decided to compile it down to native java bytecode precisely so we could take advantage of all the native Java tools that work with standard Java-like classes, such as debuggers, profilers, and even just stack traces. That approach doesn't work so well for languages that don't match Java relatively closely (i.e. stack traces in Closure are, I understand, pretty horrific), but for our language it's turned out pretty well.
- naner 16y ago
  Or as Steve Yegge claims, the programming language doesn't matter nearly as much as the tools: http://vimeo.com/16069687 http://vimeo.com/16069687
  - 16y ago
pepsi_can 16y ago
I've always used debuggers as a faster form of print statements. It faster to inspect several values using the debugger than it is to write and then delete a bunch of print statements. However print statements become my go-to tool when debugging multithreaded code.

28 points by abraham 16y ago

How many people use debuggers like GDB day-to-day? I've found them useful when trapped in a corner, but typically I debug with the source in hand. Anyone got any good debugging war stories?

abhijitr 16y ago
I would assert that it is pure folly to attempt to build a non-trivial application in a compiled language without the assistance of a competent debugger. You simply cannot iterate quickly enough through the debugging loop of "Form theory" -> "Test theory" if you have to wait a minute for a build to complete each time. Unit tests help, but will never get you all the way there (good luck tracking down a leak with unit tests).
- nickik 16y ago
  the repl is your friend even in compiled languages like haskell.
  - Devilboy 16y ago
    A proper REPL can do a lot of the same stuff you'd use a debugger for, and a whole lot more. With a nice REPL you'll do just fine without a debugger.
    - arethuza 16y ago
      Why not use a REPL and a good debugger? It's a nice combination.
- enneff 16y ago
  I consider myself a "competent debugger". ;-) But more seriously: one of Go's selling points is fast compilation times. Even for large projects compilation is mostly I/O bound, which typically means sub-second compiles.
konad 16y ago
The Plan9 debugger, ACID is awesome, even in Unix. http://swtch.com/plan9port/man/man1/acid.html http://swtch.com/plan9port/man/man1/acid.html You can debug a kernel on a remote machine with a different architecture. Shame that we've got to go back to the dark ages of GDB for Go.
- enneff 16y ago
  We have plans to build a more fully-featured, Go-centric compiler (and there's the beginnings of one in the source tree under pkg/exp/ogle), but we haven't had the time to get stuck into it yet.

hartror 16y ago

When it comes to debugging, nothing beats a few strategic print statements to inspect variables or a well-placed panic to obtain a stack trace. I respectfully disagree with this statement. Beyond simple issues a debugger is invaluable for following program flow and inspecting variable/memory states. And why does "missing .. patience" mean you are more likely to use a debugger over a print statement?

supersillyus 16y ago
In the last decade, I think I've pulled out a debugger only a handful of times. Apparently many people use them, but for me, understanding my code, writing tests, and tossing in some printfs has always been the way. I don't have a problem with debuggers, butfor me it is usually about having theories and testing them. This testing can happen in a debugger or in a print statement or in a test, but a test always seems like the best idea, and a print statement usually seems more straightforward to me than trying to stop and inspect my program while it is running.
- itsnotvalid 16y ago
  Most of the time, for me, debuggers are only used on assembly code, which it is not as easy to insert a print statement or a hook.
- barrkel 16y ago
  You use this "my" word a lot. I personally use debuggers for debugging other people's code, code that's possibly decades old, that doesn't have enough modularity for good unit tests, and whose bugs in any case often only show up in complex multithreaded integration scenarios. GDB only acquired multiprocessing debugging support this year; to my mind it's pretty primitive.

akeefer 16y ago

One of the first things you will find out, if you attempt to write a new programming language and then use it for actual production work, is how much users of that language will miss simple, taken-for-granted things like debuggers. Creating a programming language by itself isn't all that hard. The real work is actually making it usable with good error messages and stack traces, tools like debuggers and profilers, editor support (if you're into that sort of thing), and documentation and specs. All of that (especially good editor support) is easily an order of magnitude more work than a parser and a compiler, and that doesn't even consider libraries you might need to write if you can't interoperate with an established language. (Spoken from personal experience, for what it's worth).

nickik 16y ago
but the real hard thing is to make a language people want to use. If you did that the rest will be done by the comunity but even then it a lot of work. One of there reasons new langauges are often targeting the JVM or the CLR. You can reuse most of the tools and libs with less work.
- akeefer 16y ago
  Exactly. Funny story there . . . we started our JVM language as interpreted, more or less, and ended up having to write our own not-so-great debugger for it. We decided to compile it down to native java bytecode precisely so we could take advantage of all the native Java tools that work with standard Java-like classes, such as debuggers, profilers, and even just stack traces. That approach doesn't work so well for languages that don't match Java relatively closely (i.e. stack traces in Closure are, I understand, pretty horrific), but for our language it's turned out pretty well.
naner 16y ago
Or as Steve Yegge claims, the programming language doesn't matter nearly as much as the tools: http://vimeo.com/16069687 http://vimeo.com/16069687
- 16y ago

pepsi_can 16y ago

I've always used debuggers as a faster form of print statements. It faster to inspect several values using the debugger than it is to write and then delete a bunch of print statements. However print statements become my go-to tool when debugging multithreaded code.