13 ms·

Go has a debugger and it's awesome

124 points by FiloSottile 11y ago

wumbernang 11y ago
No no no no. This is not right. 1. If you debug with this, you're debugging different code to what blew up in production for example. Subtle timing issues wiped out instantly and memory ballooning masked etc. 2. If you leave it in for prod, it's going to have masses of call overhead. You can debug well with assertions, logging and unit tests. There is no need for this. I rarely have to spin up a debugger these days.
- danparsonson 11y ago
  Indeed, it's like they've never heard of the term 'Heisenbug'
  - gohrt 11y ago
    It's like they know that not all bugs are Heisenbugs.
    - danparsonson 11y ago
      Well that's a fair comment! It seems strange to me to describe debugging by instrumentation as 'awesome' - 'adequate' seems more appropriate to me. But then I'm not a Go developer so I don't know how the rest of the toolchain compares.
- alfonsodev 11y ago
  I use de Node.js debugger a lot, I think is very useful when you don't know exactly what to log, and you don't what to start adding logging lines everywhere. You have one assumption but if you are wrong you can check different var, within the debugger step by step. Sometimes I even use the debugger inside a unit test.
- simi_ 11y ago
  The last time I used a debugger was when with VS/C# or IntelliJ/Java, many years ago. For the coding I do now, mostly Go/Python/JS, I find manual debugging techniques much more effective.
- 0xdeadbeefbabe 11y ago
  > No no no no. This is not right. It's as worthwhile as the bugs they can find with it. I wish the author would tell us if he found the bug in the dns program.
thoman23 11y ago
"Go has a debugger" The very fact that that is a headline make me think I'll wait a bit before introducing Go into my tech stack.
- timclark 11y ago
  You can use gdb - https://golang.org/doc/gdb https://golang.org/doc/gdb
  - codingvelocity 11y ago
    It's largely accepted that while you can use gdb, it's not really good at debugging go code. from your own link.. "GDB does not understand Go programs well" https://github.com/derekparker/delve https://github.com/derekparker/delve delve as mentioned other places is more of a true go debugger
  - 4ad 11y ago
    You can also use mdb[1] though mdb is somewhat more suited to debugging the Go runtime itself rather then user programs. Mdb support for Go will be significantly improved in the short term. Also note that since Go has (optional) frame pointers, tools like DTrace, ktap, kprobes and uprobes, etc work much better (almost as well as for C). SystemTap works too, just that it chokes on Go DWARF without a patch. I will probably fix this soon. [1] https://www.joyent.com/blog/mdb-support-for-go https://www.joyent.com/blog/mdb-support-for-go
- _ak 11y ago
  I think you should ask yourself how all these tech companies that use Go in production ever reached the confidence to use Go in production without a "proper" debugger available.
  - pjmlp 11y ago
    It is made by Google, and has Plan9 guys on the team, what else do you need?!
metafex 11y ago
That's no debugger. That's a debugger: https://github.com/derekparker/delve https://github.com/derekparker/delve If you want to attach to running processes, use delve, it's awesome. For me personally, even with Go's short build times, you can't just deploy a new binary into a running system to see where a problem lies. Sometimes there is just no way around a traditional debugger.
- SixSigma 11y ago
  No, this is a debugger http://plan9.bell-labs.com/sys/doc/acidpaper.html http://plan9.bell-labs.com/sys/doc/acidpaper.html or on Unix https://swtch.com/plan9port/man/man1/acid.html https://swtch.com/plan9port/man/man1/acid.html Watch it in action https://www.youtube.com/watch?v=ZlGFdflPcFo https://www.youtube.com/watch?v=ZlGFdflPcFo
  - 4ad 11y ago
    Acid is great, the best debugger I know, unfortunately the Unix port in plan9port is completely non-functional. Go is really annoying to debug in acid though, because symbols contain dot characters. Somewhat ironically this was done because Unix debuggers were getting confused by the unicode middle dot character, so the unicode middle dot is replaced in the symbol and debug tables with a regular dot. But on Plan 9 we should not do this process and we should keep the original middle dot.
  - 0xdeadbeefbabe 11y ago
    cool, it reminds me os DOS's debug.
flippinburgers 11y ago
I fundamentally dislike this approach to solving the problem. It feels very crude.
shawnps 11y ago
I also use a well-known debugger called fmt.Println
bcantrill 11y ago
As someone who has dedicated their career to understanding and debugging software in production[1], it's hard to not be depressed about this -- not only because it (emphatically) isn't "awesome", but also because of the failure to couch this in its proper context: this is -- at best -- a kludge to enable small programs to be debugged in development. While this is fine at some level (debugging is, after all, a good thing), small programs in development aren't where the most pernicious bugs are found; sophisticated tooling should (in my opinion) always focus on the production systems in which the nastiest, most undebuggable problems arise. Note that this needn't mean that the tools themselves run in production: for example, Valgrind is incredibly useful because it finds really nasty, production-grade issues -- even if it is only meaningfully usable in development. Similarly, postmortem debugging tooling is extraordinarily valuable for production problems -- and requires no tooling in the production environment itself. We have developed such tooling for node.js[2], and found it to be invaluable. There is nascent postmortem debugging support for Go[3], but there is much more to be done -- just hoping that some in the Go community see the value of debugging production problems! [1] http://www.infoq.com/presentations/Debugging-Production-Systems http://www.infoq.com/presentations/Debugging-Production-Syst... [2] http://www.slideshare.net/bcantrill/node-summit2013 http://www.slideshare.net/bcantrill/node-summit2013 [3] http://www.joyent.com/blog/mdb-support-for-go http://www.joyent.com/blog/mdb-support-for-go
- 4ad 11y ago
  > just hoping that some in the Go community see the value of debugging production problems Some of us do. As I said in another post, Solaris support will only get better. As for Linux, some people obviously care, Go had some form of gdb support from quite early on. Unfortunately, it's not that people don't care about making the gdb support better, it's just that this is all that can be done with the gdb-python interface right now, due to the limitations of gdb... At least, now with frame pointers, dynamic instrumentation works better.
- vruiz 11y ago
  > just hoping that some in the Go community see the value of debugging production problems! I just can not remember where I heard it (some podcast maybe), but is my understanding that the Go Team hinted the possibility of something like JMX coming to the Go runtime.
pstuart 11y ago
Wasn't ogle supposed to be the official debugger? https://godoc.org/golang.org/x/debug/ogle/program https://godoc.org/golang.org/x/debug/ogle/program
tenfingers 11y ago
A debugger that cannot be attached to a living process, that cannot change or execute data dynamically, is not a debugger. Unfortunately, many languages provide "debuggers" that fall into that category.
- istvan__ 11y ago
  Well I guess the Go community is a little bit too passionate about any update regarding Go, even if the introduced new thing is subpar compare to other languages, like this one in the post.
  - tenfingers 11y ago
    I think that the main issue is that debuggers are often dismissed in terms of importance, and many don't see the true value of debugging beyond simple step-by-step execution. This is not unique to Go: python's several debuggers require cooperation with the inspected process. This is exactly the opposite of a buggy situation. gdb's python support is very limited in terms of debugging capabilities, yet it's the only option you have if you're using an external event loop handler, such as gtk/qt/glib (not so uncommon). I guess I should be grateful I have those at least.
    - istvan__ 11y ago
      I absolutely agree with you, my problem is that if I bring these things up in an discussion about languages it results in "who are you kidding, we don't need that feature!" sort of comments. Personally I find it hard to do any sort of computation without the ability is inspect what is going inside.
alkonaut 11y ago
While I understand that this is a fairly young language, it still makes me sad that we seem to erode what's actually cool, what's a good language, what good tools are. It took us two decades to massage the "last" generation of tools, the managed/OO ones, into shape. I've been whining about javas lack of value types, or that java tools didn't allow editing and reloading the debugged code in-place. I have whined for years about how the C# debugger doesn't allow edit-and-continue in 64bit, or how watch expressions can't have lambdas in them. Meanwhile, outside my windows, it seems the world pretty much just rejected types, debuggers... "You can do println debugging and generics will just make the language too hard to learn and the runtime too complex". It used to be the other way around. I was young and the old guys used to say "I'll use my punchcard/command line debugger/whatever, you kids can use your fancy IDE all you want". Now I sound like a dinosaur for wanting to edit my code in place while debugging, and for being whiny about type systems. What the hell happened? Also, get off my lawn.
- Someone1234 11y ago
  > C# debugger doesn't allow edit-and-continue in 64bit They added that two years ago: http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/26/debugging-support-for-64-bit-edit-and-continue-in-visual-studio-2013.aspx http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/26/d... > or how watch expressions can't have lambdas in them. That's a limitation on how lambdas work. Doubt it could be solved.
  - stcredzero 11y ago
    That's a limitation on how lambdas work. Doubt it could be solved. AFAIK, this wasn't a problem with Smalltalk. Watch expressions would have worked in somewhat the same way as conditional breakpoints, and you couldn't have those without allowing Blocks, which are the equivalent of Smalltalk lambdas. This may be a problem with the CLR, though.
  - alkonaut 11y ago
    They add watch lambdas in vs2015. Maybe Roslyn enabled it, not sure.
  - 11y ago
dsl 11y ago
Could a mod please update this to point to the original announcement and not the CloudFlare regurgitation? The Mailgun folks deserve the love for their hard work. http://blog.mailgun.com/introducing-a-new-cross-platform-debugger-for-go/ http://blog.mailgun.com/introducing-a-new-cross-platform-deb...
- dang 11y ago
  I was just looking into that. Normally we would do so, but that post already had a major thread: https://news.ycombinator.com/item?id=9409423 https://news.ycombinator.com/item?id=9409423.
- deleted 11y ago
  [deleted]
stcredzero 11y ago
Before closing, I'd like to say a few words about the technique of source rewriting in general. It powers many different Go tools, like test coverage, fuzzing and, indeed, debugging. It's made possible primarily by Go’s blazing-fast compiles, and it enables amazing cross-platform tools to be built easily. Source rewriting is indeed quite powerful. You can use this technique to write a code coverage tool in Smalltalk. (Grab the source code of a method, apply parser-transformations, compile an instrumented version, swap the bytecode of the original method with the instrumented one. Make the instrumented method know how to swap itself back when everything is triggered.) A typical developer can write such a tool and have it become functional in one or two days. An exceptional one can do it in hours. Iterating more produces more innovative applications and software tools. This is why fast compiles and parser tools are a winning combination.

124 points by FiloSottile 11y ago

No no no no. This is not right. 1. If you debug with this, you're debugging different code to what blew up in production for example. Subtle timing issues wiped out instantly and memory ballooning masked etc. 2. If you leave it in for prod, it's going to have masses of call overhead. You can debug well with assertions, logging and unit tests. There is no need for this. I rarely have to spin up a debugger these days.

danparsonson 11y ago
Indeed, it's like they've never heard of the term 'Heisenbug'
- gohrt 11y ago
  It's like they know that not all bugs are Heisenbugs.
  - danparsonson 11y ago
    Well that's a fair comment! It seems strange to me to describe debugging by instrumentation as 'awesome' - 'adequate' seems more appropriate to me. But then I'm not a Go developer so I don't know how the rest of the toolchain compares.
alfonsodev 11y ago
I use de Node.js debugger a lot, I think is very useful when you don't know exactly what to log, and you don't what to start adding logging lines everywhere. You have one assumption but if you are wrong you can check different var, within the debugger step by step. Sometimes I even use the debugger inside a unit test.
simi_ 11y ago
The last time I used a debugger was when with VS/C# or IntelliJ/Java, many years ago. For the coding I do now, mostly Go/Python/JS, I find manual debugging techniques much more effective.
0xdeadbeefbabe 11y ago
> No no no no. This is not right. It's as worthwhile as the bugs they can find with it. I wish the author would tell us if he found the bug in the dns program.

thoman23 11y ago

"Go has a debugger" The very fact that that is a headline make me think I'll wait a bit before introducing Go into my tech stack.

timclark 11y ago
You can use gdb - https://golang.org/doc/gdb https://golang.org/doc/gdb
- codingvelocity 11y ago
  It's largely accepted that while you can use gdb, it's not really good at debugging go code. from your own link.. "GDB does not understand Go programs well" https://github.com/derekparker/delve https://github.com/derekparker/delve delve as mentioned other places is more of a true go debugger
- 4ad 11y ago
  You can also use mdb[1] though mdb is somewhat more suited to debugging the Go runtime itself rather then user programs. Mdb support for Go will be significantly improved in the short term. Also note that since Go has (optional) frame pointers, tools like DTrace, ktap, kprobes and uprobes, etc work much better (almost as well as for C). SystemTap works too, just that it chokes on Go DWARF without a patch. I will probably fix this soon. [1] https://www.joyent.com/blog/mdb-support-for-go https://www.joyent.com/blog/mdb-support-for-go
_ak 11y ago
I think you should ask yourself how all these tech companies that use Go in production ever reached the confidence to use Go in production without a "proper" debugger available.
- pjmlp 11y ago
  It is made by Google, and has Plan9 guys on the team, what else do you need?!

metafex 11y ago

That's no debugger. That's a debugger: https://github.com/derekparker/delve https://github.com/derekparker/delve If you want to attach to running processes, use delve, it's awesome. For me personally, even with Go's short build times, you can't just deploy a new binary into a running system to see where a problem lies. Sometimes there is just no way around a traditional debugger.

SixSigma 11y ago
No, this is a debugger http://plan9.bell-labs.com/sys/doc/acidpaper.html http://plan9.bell-labs.com/sys/doc/acidpaper.html or on Unix https://swtch.com/plan9port/man/man1/acid.html https://swtch.com/plan9port/man/man1/acid.html Watch it in action https://www.youtube.com/watch?v=ZlGFdflPcFo https://www.youtube.com/watch?v=ZlGFdflPcFo
- 4ad 11y ago
  Acid is great, the best debugger I know, unfortunately the Unix port in plan9port is completely non-functional. Go is really annoying to debug in acid though, because symbols contain dot characters. Somewhat ironically this was done because Unix debuggers were getting confused by the unicode middle dot character, so the unicode middle dot is replaced in the symbol and debug tables with a regular dot. But on Plan 9 we should not do this process and we should keep the original middle dot.
- 0xdeadbeefbabe 11y ago
  cool, it reminds me os DOS's debug.

flippinburgers 11y ago

I fundamentally dislike this approach to solving the problem. It feels very crude.

shawnps 11y ago

I also use a well-known debugger called fmt.Println

bcantrill 11y ago

As someone who has dedicated their career to understanding and debugging software in production[1], it's hard to not be depressed about this -- not only because it (emphatically) isn't "awesome", but also because of the failure to couch this in its proper context: this is -- at best -- a kludge to enable small programs to be debugged in development. While this is fine at some level (debugging is, after all, a good thing), small programs in development aren't where the most pernicious bugs are found; sophisticated tooling should (in my opinion) always focus on the production systems in which the nastiest, most undebuggable problems arise. Note that this needn't mean that the tools themselves run in production: for example, Valgrind is incredibly useful because it finds really nasty, production-grade issues -- even if it is only meaningfully usable in development. Similarly, postmortem debugging tooling is extraordinarily valuable for production problems -- and requires no tooling in the production environment itself. We have developed such tooling for node.js[2], and found it to be invaluable. There is nascent postmortem debugging support for Go[3], but there is much more to be done -- just hoping that some in the Go community see the value of debugging production problems! [1] http://www.infoq.com/presentations/Debugging-Production-Systems http://www.infoq.com/presentations/Debugging-Production-Syst... [2] http://www.slideshare.net/bcantrill/node-summit2013 http://www.slideshare.net/bcantrill/node-summit2013 [3] http://www.joyent.com/blog/mdb-support-for-go http://www.joyent.com/blog/mdb-support-for-go

4ad 11y ago
> just hoping that some in the Go community see the value of debugging production problems Some of us do. As I said in another post, Solaris support will only get better. As for Linux, some people obviously care, Go had some form of gdb support from quite early on. Unfortunately, it's not that people don't care about making the gdb support better, it's just that this is all that can be done with the gdb-python interface right now, due to the limitations of gdb... At least, now with frame pointers, dynamic instrumentation works better.
vruiz 11y ago
> just hoping that some in the Go community see the value of debugging production problems! I just can not remember where I heard it (some podcast maybe), but is my understanding that the Go Team hinted the possibility of something like JMX coming to the Go runtime.

pstuart 11y ago

Wasn't ogle supposed to be the official debugger? https://godoc.org/golang.org/x/debug/ogle/program https://godoc.org/golang.org/x/debug/ogle/program

tenfingers 11y ago

A debugger that cannot be attached to a living process, that cannot change or execute data dynamically, is not a debugger. Unfortunately, many languages provide "debuggers" that fall into that category.

istvan__ 11y ago
Well I guess the Go community is a little bit too passionate about any update regarding Go, even if the introduced new thing is subpar compare to other languages, like this one in the post.
- tenfingers 11y ago
  I think that the main issue is that debuggers are often dismissed in terms of importance, and many don't see the true value of debugging beyond simple step-by-step execution. This is not unique to Go: python's several debuggers require cooperation with the inspected process. This is exactly the opposite of a buggy situation. gdb's python support is very limited in terms of debugging capabilities, yet it's the only option you have if you're using an external event loop handler, such as gtk/qt/glib (not so uncommon). I guess I should be grateful I have those at least.
  - istvan__ 11y ago
    I absolutely agree with you, my problem is that if I bring these things up in an discussion about languages it results in "who are you kidding, we don't need that feature!" sort of comments. Personally I find it hard to do any sort of computation without the ability is inspect what is going inside.

alkonaut 11y ago

While I understand that this is a fairly young language, it still makes me sad that we seem to erode what's actually cool, what's a good language, what good tools are. It took us two decades to massage the "last" generation of tools, the managed/OO ones, into shape. I've been whining about javas lack of value types, or that java tools didn't allow editing and reloading the debugged code in-place. I have whined for years about how the C# debugger doesn't allow edit-and-continue in 64bit, or how watch expressions can't have lambdas in them. Meanwhile, outside my windows, it seems the world pretty much just rejected types, debuggers... "You can do println debugging and generics will just make the language too hard to learn and the runtime too complex". It used to be the other way around. I was young and the old guys used to say "I'll use my punchcard/command line debugger/whatever, you kids can use your fancy IDE all you want". Now I sound like a dinosaur for wanting to edit my code in place while debugging, and for being whiny about type systems. What the hell happened? Also, get off my lawn.

Someone1234 11y ago
> C# debugger doesn't allow edit-and-continue in 64bit They added that two years ago: http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/26/debugging-support-for-64-bit-edit-and-continue-in-visual-studio-2013.aspx http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/26/d... > or how watch expressions can't have lambdas in them. That's a limitation on how lambdas work. Doubt it could be solved.
- stcredzero 11y ago
  That's a limitation on how lambdas work. Doubt it could be solved. AFAIK, this wasn't a problem with Smalltalk. Watch expressions would have worked in somewhat the same way as conditional breakpoints, and you couldn't have those without allowing Blocks, which are the equivalent of Smalltalk lambdas. This may be a problem with the CLR, though.
- alkonaut 11y ago
  They add watch lambdas in vs2015. Maybe Roslyn enabled it, not sure.
- 11y ago

dsl 11y ago

Could a mod please update this to point to the original announcement and not the CloudFlare regurgitation? The Mailgun folks deserve the love for their hard work. http://blog.mailgun.com/introducing-a-new-cross-platform-debugger-for-go/ http://blog.mailgun.com/introducing-a-new-cross-platform-deb...

dang 11y ago
I was just looking into that. Normally we would do so, but that post already had a major thread: https://news.ycombinator.com/item?id=9409423 https://news.ycombinator.com/item?id=9409423.
deleted 11y ago
[deleted]

stcredzero 11y ago

Before closing, I'd like to say a few words about the technique of source rewriting in general. It powers many different Go tools, like test coverage, fuzzing and, indeed, debugging. It's made possible primarily by Go’s blazing-fast compiles, and it enables amazing cross-platform tools to be built easily. Source rewriting is indeed quite powerful. You can use this technique to write a code coverage tool in Smalltalk. (Grab the source code of a method, apply parser-transformations, compile an instrumented version, swap the bytecode of the original method with the instrumented one. Make the instrumented method know how to swap itself back when everything is triggered.) A typical developer can write such a tool and have it become functional in one or two days. An exceptional one can do it in hours. Iterating more produces more innovative applications and software tools. This is why fast compiles and parser tools are a winning combination.