Hacker News Reader

Comment by thoman23 | Hacker News Reader

"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.

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.

It is made by Google, and has Plan9 guys on the team, what else do you need?!

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.

No, it's a very valid concern. It's quite plausible that the absence of a debugger slows down the roll out to production.

Having a debugger is not the only way to debug. Thinking otherwise is not thinking.

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.

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?

> 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.

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.

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.

You can use gdb - https://golang.org/doc/gdb

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 delve as mentioned other places is more of a true go debugger

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

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.

Reply on news.ycombinator.com