4 ms·

"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?!
  - _ak 11y ago
    The point I'm trying to make is that you can develop and debug Go code perfectly fine without a debugger, as shown by the large-scale deployments of software written in Go. Not adding Go to your tech stack because of that is... not very well thought through, to say the least.
    - deleted 11y ago
      [deleted]
    - zak_mc_kracken 11y ago
      No, it's a very valid concern. It's quite plausible that the absence of a debugger slows down the roll out to production.
      - 0xdeadbeefbabe 11y ago
        Having a debugger is not the only way to debug. Thinking otherwise is not thinking.
        zak_mc_kracken 11y ago
        I never said it was the only way to debug, just that between a language that only supports `printf` and one that supports `printf` and a debugger, the latter is obviously a more productive environment to work in.
- zak_mc_kracken 11y ago
  Replace "Go" with "PHP" and ask yourself if such a claim is a strong validation of a technology...' Yes, a lot of people have gone to production with crappy technologies, this is meaningless. The real question is: could they have done it more easily using a better technology?
  - furyofantares 11y ago
    > Yes, a lot of people have gone to production with crappy technologies, this is meaningless. I don't think that's meaningless. I take it to mean that your (our, my) valuation of technologies does not hold the relative importance (or correctness) that it's perceived to hold.
  - stcredzero 11y ago
    Replace "Go" with "PHP" and ask yourself if such a claim is a strong validation of a technology...' As a programmer using Go, I think the comparison is spot on -- if you credit Go for having a much cleaner architecture, vastly better design around security, and profoundly well thought out trade offs. With some work on libraries and tooling, Go could well become the basis of the next PHP, and become the tool of choice for small web projects. If this happened, the world would be a better (in terms of software-sanity, performance, and security) place.
- jlarocco 11y ago
  I'm not sure that's a very good argument. 50 years ago there were a ton of companies that were confidently using hex machine code for large systems in production. That doesn't mean things wouldn't have been 100x easier for them with higher level languages and more modern tools. Of course I can get by without a debugger if I really need to, but that doesn't mean I won't be a lot more productive with one.
PopsiclePete 11y ago
If you can't write code without a debugger, then absolutely, wait. I'd straight-up refuse to write C#/Java without a debugger as well - too many layers and obfuscation. Go, however, is kind of like a memory-safe C...it's almost impossible to actually create super high-level abstractions where you can't tell what the code is doing. For me, unit tests and the occasional log/print cover 99% of my Go debugging needs.

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?!
- _ak 11y ago
  The point I'm trying to make is that you can develop and debug Go code perfectly fine without a debugger, as shown by the large-scale deployments of software written in Go. Not adding Go to your tech stack because of that is... not very well thought through, to say the least.
  - deleted 11y ago
    [deleted]
  - zak_mc_kracken 11y ago
    No, it's a very valid concern. It's quite plausible that the absence of a debugger slows down the roll out to production.
    - 0xdeadbeefbabe 11y ago
      Having a debugger is not the only way to debug. Thinking otherwise is not thinking.
      - zak_mc_kracken 11y ago
        I never said it was the only way to debug, just that between a language that only supports `printf` and one that supports `printf` and a debugger, the latter is obviously a more productive environment to work in.
zak_mc_kracken 11y ago
Replace "Go" with "PHP" and ask yourself if such a claim is a strong validation of a technology...' Yes, a lot of people have gone to production with crappy technologies, this is meaningless. The real question is: could they have done it more easily using a better technology?
- furyofantares 11y ago
  > Yes, a lot of people have gone to production with crappy technologies, this is meaningless. I don't think that's meaningless. I take it to mean that your (our, my) valuation of technologies does not hold the relative importance (or correctness) that it's perceived to hold.
- stcredzero 11y ago
  Replace "Go" with "PHP" and ask yourself if such a claim is a strong validation of a technology...' As a programmer using Go, I think the comparison is spot on -- if you credit Go for having a much cleaner architecture, vastly better design around security, and profoundly well thought out trade offs. With some work on libraries and tooling, Go could well become the basis of the next PHP, and become the tool of choice for small web projects. If this happened, the world would be a better (in terms of software-sanity, performance, and security) place.
jlarocco 11y ago
I'm not sure that's a very good argument. 50 years ago there were a ton of companies that were confidently using hex machine code for large systems in production. That doesn't mean things wouldn't have been 100x easier for them with higher level languages and more modern tools. Of course I can get by without a debugger if I really need to, but that doesn't mean I won't be a lot more productive with one.

PopsiclePete 11y ago

If you can't write code without a debugger, then absolutely, wait. I'd straight-up refuse to write C#/Java without a debugger as well - too many layers and obfuscation. Go, however, is kind of like a memory-safe C...it's almost impossible to actually create super high-level abstractions where you can't tell what the code is doing. For me, unit tests and the occasional log/print cover 99% of my Go debugging needs.