12 ms·

Still no real debugger?

thegeekpirate 11y ago
https://golang.org/doc/gdb https://golang.org/doc/gdb https://github.com/derekparker/delve https://github.com/derekparker/delve
- XorNot 11y ago
  gdb is not a real option at the moment. Being unable to easily parse through maps wipes and slices wipes out most of the actual use cases.
icedchai 11y ago
printf isn't good enough for you?
- lemevi 11y ago
  Logging can be of great practical utility, but being able to stop a program and freeze it in its state to figure things out is also pretty nice right. You can walk up and down the stack, inspect the scope and the state of things, walk through line after line of code to try and find things in a way that would take a really long time with logging. So no, printf is not good enough. That's why people have created debuggers.
  - enahs-sf 11y ago
    While I can see the argument for and against printf, with the cpu and memory profiling tools, you can basically figure out where most of the issues in your code are. I'd say for most applications, logging, printf, etc. can get you 80% of the way there. Profiling gets you another 10%. For those last mile apps, sorry, but you have to use GDB.
    - TillE 11y ago
      If you don't care how long it takes, sure, tracing with printf works. But a debugger accomplishes the same task in minutes rather than hours. Even if you know only the very basics of how to use a debugger, it's an extremely effective tool.
      - ska 11y ago
        It's not always effective - many developers will often save minutes of thinking by spending hours dicking about in a debugger and setting up state. But it is true that for some types of bugs a step debugger is damn handy. And for some types, mostly a distraction.
- vvanders 11y ago
  This attitude is so toxic, it's like saying isn't assembler good enough for you? Good tools matter, there's nothing more painful then a platform where your only debugging is printf.
  - fit2rule 11y ago
    Good tools take time. Complaining about not having them is not very sporting behaviour. Fact is, if you don't have a tool, use printf-style debugging. It has worked for computers since before the very first debugger was ever made, and as a skill it should not be discounted in favour of more, shall we say .. consumer-ist .. attitudes about what 'should' and 'should not' be a normative in programming toolkits. No debugger? No problem. Debuggers are a luxury and a time-saver, but knowing your code-base well enough, because you printf-debug too, is also a time-saver.
    - vvanders 11y ago
      If you read carefully, you'll see that I was saying the "good enough" attitude is toxic. I was not complaining about not having the tools(I don't even write Go) and a contributor mentioned above that it just wasn't a priority(which I have some beef with) but is a fair statement. There are some problems that can't be solved by printf debugging. They include: -GPU Performance profiling: All your commands are async and appear immediate, teasing out performance characteristics takes a massive suite of tests and may not even reproduce your issue. -Thread concurrency issues: Adding a printf can actually make these bugs disappear as printf usually has some sort of memory fence or flush semantics that change behaviour. -Platforms that can't handle large amounts of trace logging: Sony PSP was one of these where each printf() required the tcp ack before the buffer would clear after a trivial amount of logs. One of the core tenants of comp sci and technology in general is building on what came before. That's where our productivity gains come from. Not taking that approach is a dangerous mentality that can have serious implications on your velocity and agility and is not a choice to be made lightly.
    - threeseed 11y ago
      > Debuggers are a luxury and a time-saver You must have only worked on toy applications before. Because debuggers are essential on any non trivial application.
- scott_karana 11y ago
  Hopefully my upvote helps counteract those who didn't realize you were being sarcastic! You made me laugh, at least :)
  - vvanders 11y ago
    Even if the original post was sarcastic I've seen this expressed seriously enough in the wild that I think it still should be addressed.
    - ithkuil 11y ago
      I use printf-debugging the vast majority of the time. But that's fine if you know you have an alternative and you're just lazy to use it. Recently I was working on an embedded platform which had no debugger support at all. There was some On-Chip debugger option, but it required some soldering and hacking some jtag cable, still too lazy. Despite the laziness, I ended up implementing gdb support for that platform, over it's normal serial port: https://blog.cesanta.com/esp8266-gdb https://blog.cesanta.com/esp8266-gdb Go at least has stack traces with no extra tooling, which is a big deal. Anyway, the more tools the better; you're gonna miss them when you need them most.
  - coldtea 11y ago
    Not sure if he was sarcastic -- tons of people say the same thing with a straight face.
  - mshenfield 11y ago
    Ditto for me :)
- coldtea 11y ago
  Why, do we only strive for "good enough" in tooling? Contrast your response to Russ Cox's answer: "We are well aware of the hole, though, and we'd like to plug it, but other work took priority this release cycle".
- rd_tech 11y ago
  For school projects, it's more than enough. For a real world enterprise development, sadly, go without a debugger/supported environment, is a no-go.
- rd_tech 11y ago
  For school projects, it's more than enough. For a real world enterprise development, sadly, go without a debugger/supported environment, is a no-go.
black_knight 11y ago
The creators being Plan 9 fans, they might want you to use Acid[0] [0] http://plan9.bell-labs.com/sys/doc/acidpaper.html http://plan9.bell-labs.com/sys/doc/acidpaper.html
- vezzy-fnord 11y ago
  plan9port's version of acid(1) is currently limited, however: https://swtch.com/plan9port/man/man1/acid.html https://swtch.com/plan9port/man/man1/acid.html See BUGS.
- rsc 11y ago
  Acid is fantastic, but I really wouldn't wish it on anyone. Incredibly powerful but incredibly awkward language.
rsc 11y ago
No, sadly. We are well aware of the hole, though, and we'd like to plug it, but other work took priority this release cycle.
- beckler 11y ago
  Any comment on what we might be able to expect in 1.6?
  - rsc 11y ago
    No, sorry. Go 1.6 planning is just beginning.
Gepsens 11y ago
At the last Gophercon Delve was presented as the go to tool, I remember the pres was fast but It was convincing enough. You're also free to add a vim or any IDE view with interaction based on it.
mbertschler 11y ago
This is a pretty good cross platform Go debugger: https://github.com/mailgun/godebug https://github.com/mailgun/godebug
voidlogic 11y ago
What is wrong with delve?

https://golang.org/doc/gdb https://golang.org/doc/gdb https://github.com/derekparker/delve https://github.com/derekparker/delve

XorNot 11y ago
gdb is not a real option at the moment. Being unable to easily parse through maps wipes and slices wipes out most of the actual use cases.

icedchai 11y ago

printf isn't good enough for you?

lemevi 11y ago
Logging can be of great practical utility, but being able to stop a program and freeze it in its state to figure things out is also pretty nice right. You can walk up and down the stack, inspect the scope and the state of things, walk through line after line of code to try and find things in a way that would take a really long time with logging. So no, printf is not good enough. That's why people have created debuggers.
- enahs-sf 11y ago
  While I can see the argument for and against printf, with the cpu and memory profiling tools, you can basically figure out where most of the issues in your code are. I'd say for most applications, logging, printf, etc. can get you 80% of the way there. Profiling gets you another 10%. For those last mile apps, sorry, but you have to use GDB.
  - TillE 11y ago
    If you don't care how long it takes, sure, tracing with printf works. But a debugger accomplishes the same task in minutes rather than hours. Even if you know only the very basics of how to use a debugger, it's an extremely effective tool.
    - ska 11y ago
      It's not always effective - many developers will often save minutes of thinking by spending hours dicking about in a debugger and setting up state. But it is true that for some types of bugs a step debugger is damn handy. And for some types, mostly a distraction.
vvanders 11y ago
This attitude is so toxic, it's like saying isn't assembler good enough for you? Good tools matter, there's nothing more painful then a platform where your only debugging is printf.
- fit2rule 11y ago
  Good tools take time. Complaining about not having them is not very sporting behaviour. Fact is, if you don't have a tool, use printf-style debugging. It has worked for computers since before the very first debugger was ever made, and as a skill it should not be discounted in favour of more, shall we say .. consumer-ist .. attitudes about what 'should' and 'should not' be a normative in programming toolkits. No debugger? No problem. Debuggers are a luxury and a time-saver, but knowing your code-base well enough, because you printf-debug too, is also a time-saver.
  - vvanders 11y ago
    If you read carefully, you'll see that I was saying the "good enough" attitude is toxic. I was not complaining about not having the tools(I don't even write Go) and a contributor mentioned above that it just wasn't a priority(which I have some beef with) but is a fair statement. There are some problems that can't be solved by printf debugging. They include: -GPU Performance profiling: All your commands are async and appear immediate, teasing out performance characteristics takes a massive suite of tests and may not even reproduce your issue. -Thread concurrency issues: Adding a printf can actually make these bugs disappear as printf usually has some sort of memory fence or flush semantics that change behaviour. -Platforms that can't handle large amounts of trace logging: Sony PSP was one of these where each printf() required the tcp ack before the buffer would clear after a trivial amount of logs. One of the core tenants of comp sci and technology in general is building on what came before. That's where our productivity gains come from. Not taking that approach is a dangerous mentality that can have serious implications on your velocity and agility and is not a choice to be made lightly.
  - threeseed 11y ago
    > Debuggers are a luxury and a time-saver You must have only worked on toy applications before. Because debuggers are essential on any non trivial application.
scott_karana 11y ago
Hopefully my upvote helps counteract those who didn't realize you were being sarcastic! You made me laugh, at least :)
- vvanders 11y ago
  Even if the original post was sarcastic I've seen this expressed seriously enough in the wild that I think it still should be addressed.
  - ithkuil 11y ago
    I use printf-debugging the vast majority of the time. But that's fine if you know you have an alternative and you're just lazy to use it. Recently I was working on an embedded platform which had no debugger support at all. There was some On-Chip debugger option, but it required some soldering and hacking some jtag cable, still too lazy. Despite the laziness, I ended up implementing gdb support for that platform, over it's normal serial port: https://blog.cesanta.com/esp8266-gdb https://blog.cesanta.com/esp8266-gdb Go at least has stack traces with no extra tooling, which is a big deal. Anyway, the more tools the better; you're gonna miss them when you need them most.
- coldtea 11y ago
  Not sure if he was sarcastic -- tons of people say the same thing with a straight face.
- mshenfield 11y ago
  Ditto for me :)
coldtea 11y ago
Why, do we only strive for "good enough" in tooling? Contrast your response to Russ Cox's answer: "We are well aware of the hole, though, and we'd like to plug it, but other work took priority this release cycle".
rd_tech 11y ago
For school projects, it's more than enough. For a real world enterprise development, sadly, go without a debugger/supported environment, is a no-go.
rd_tech 11y ago
For school projects, it's more than enough. For a real world enterprise development, sadly, go without a debugger/supported environment, is a no-go.

black_knight 11y ago

The creators being Plan 9 fans, they might want you to use Acid[0] [0] http://plan9.bell-labs.com/sys/doc/acidpaper.html http://plan9.bell-labs.com/sys/doc/acidpaper.html

vezzy-fnord 11y ago
plan9port's version of acid(1) is currently limited, however: https://swtch.com/plan9port/man/man1/acid.html https://swtch.com/plan9port/man/man1/acid.html See BUGS.
rsc 11y ago
Acid is fantastic, but I really wouldn't wish it on anyone. Incredibly powerful but incredibly awkward language.

rsc 11y ago

No, sadly. We are well aware of the hole, though, and we'd like to plug it, but other work took priority this release cycle.

beckler 11y ago
Any comment on what we might be able to expect in 1.6?
- rsc 11y ago
  No, sorry. Go 1.6 planning is just beginning.

Gepsens 11y ago

At the last Gophercon Delve was presented as the go to tool, I remember the pres was fast but It was convincing enough. You're also free to add a vim or any IDE view with interaction based on it.

mbertschler 11y ago

This is a pretty good cross platform Go debugger: https://github.com/mailgun/godebug https://github.com/mailgun/godebug

voidlogic 11y ago

What is wrong with delve?