Hacker News Reader

Comment by coldcode | Hacker News Reader

Go was interesting me to up to the point that I found out there is no real debugger, and little interest in making one. I find it hard to get excited about being unable to properly debug my code.

View on HN

"little interest in making one" is a bit of a bold statement... Sure a lot of the early Go users thought/preached "gdb is good enough", but I don't feel that's the case anymore.

For example, mailgun's https://github.com/mailgun/godebug looks very promising.

jschlatter just wrote a great blog post about this:

http://blog.mailgun.com/introducing-a-new-cross-platform-deb...

Strange as I was just debugging my go code. http://postimg.org/image/prgj1qjzn/

Care to explain me how I'm debugging some la,guage that has no debugger?

LiteIDE, which uses gdb in the background, isn't reliable.

golang.org/doc/gdb: "although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones"

https://github.com/derekparker/delve

There is a talk scheduled on this at GopherCon 2016. Make sure you have a look at it.

What I'm going to say won't make much sense at first, but I find I don't really need a debugger when writing Go. A log statement here and there combined with unit tests and the race detector get me through every time.

I absolutely refuse to touch Java/C#/C++ without a debugger, but that's because they're a lot more "magical" - lots of layers, lots of magic, 'heavy' types.

Go is a lot more explicit about what's going. It is more verbose, yes, but you also know how things work by just looking at them.

I'd love a debugger for Go, sure, but I just don't need one.

There are some okay debugging options but I also agree with parent that debuggers are useful. Especially when learning a language and trying to tease out WTF is going on. When you don't understand the meta of the print statement especially. And you don't yet grok the testing framework.

Now there's a good interview question to determine if you're the type of person who gets things done. Plenty of code has been written without "real debuggers".

A debugger can make things easier, but can you effectively work without one if needed?

Sometimes stepping through is faster than adding in trace temporarily. I say that as someone who almost always uses trace. This is a terrible interview question if "yes I use a debugger" is the wrong answer. What matters is if the person can get the job done, not if they'd do it the same way as you.

There's nothing wrong with using a debugger. If you tell me you can't or won't solve a problem without a debugger, well ...

You are shifting the goalposts. The original commenter just stated that they didn't feel enthusiastic about using a language without a debugger. Not that they couldn't solve a problem without a debugger.

The type of argument you are making has been used throughout the history of computing as a reason to avoid using computers to solve problems. For literally any problem that is solvable by computers, you can make an argument about how using a computer to do it means you lose the ability to solve it by hand. From accounting to engineering to programming to administration to physics to writing, in all these areas (and more) older practitioners have bemoaned the use of computers to quickly and accurately solve problems that they have spent a lifetime mastering how to solve by hand. The reason for their opposition is pretty clear.

I don't know why this type of attitude is so prevalent among some sections of the programmer community. Programmers are the people who should most of all appreciate the ability of computers to automate tedious and error prone tasks. Yet for a certain class of easily automatable programming problems there is a group of programmers who resist very strongly the use of computers to automate. Maybe it's just the same old issue of not wanting to admit that something they spent a long time mastering isn't very useful anymore and that they are getting outcompeted in the marketplace. I think there is a bit of unpleasant machismo about it as well though; the idea that you aren't a 'real' programmer unless you eschew a certain level of automation (be that high level languages or compilers or version control or automated build systems or syntax highlighting or tools to refactor code etc).

No, I didn't shift the goal post. I added an extra sentence to fix the "parse error". I use a Xcode debugger when it works, for example. However, I'm also able to effectively debug my code when Apple breaks it. I've been dropped in to debug JavaScript in IE7, for instance, and told that I couldn't install Chrome to debug it because it "wasn't a corporate standard".

Someone who wants a complete ecosystem before they can be effective strikes me as a problem.

I'm fairly certain I would have zero desire to work someplace that considers 'Yes, i use a debugger' the wrong answer.

That wasn't the question.

>Sometimes stepping through is faster than adding in trace temporarily.

Using trace? ...

Real programmers use print statements...

Plenty of cars have been made without a three-point seat-belt.

I write plenty of Go in my time off but professionally I write C# in Visual Studio and the debugger is amazing. It's saved me thousands of hours cumulatively over the years. I like Go a lot, but lack of a proper debugger can definitely be seen as an argument against it by someone considering the language.

>Plenty of cars have been made without a three-point seat-belt

And? Who said it's that better? How many died or didn't die anyway?

I mostly write java, and only very rarely use the debugger. If I need to verify or poke behaviour, I generally write a test to find out. Stack races and tests are usually enough.

Reply on news.ycombinator.com