Debugging Go code (a status report) | Hacker News Reader

Debugging Go code (a status report)

blog.golang.org

28 pointsabraham18 comments

One of the first things you will find out, if you attempt to write a new programming language and then use it for actual production work, is how much users of that language will miss simple, taken-for-granted things like debuggers.

Creating a programming language by itself isn't all that hard. The real work is actually making it usable with good error messages and stack traces, tools like debuggers and profilers, editor support (if you're into that sort of thing), and documentation and specs. All of that (especially good editor support) is easily an order of magnitude more work than a parser and a compiler, and that doesn't even consider libraries you might need to write if you can't interoperate with an established language. (Spoken from personal experience, for what it's worth).

but the real hard thing is to make a language people want to use. If you did that the rest will be done by the comunity but even then it a lot of work.

One of there reasons new langauges are often targeting the JVM or the CLR. You can reuse most of the tools and libs with less work.

Exactly. Funny story there . . . we started our JVM language as interpreted, more or less, and ended up having to write our own not-so-great debugger for it. We decided to compile it down to native java bytecode precisely so we could take advantage of all the native Java tools that work with standard Java-like classes, such as debuggers, profilers, and even just stack traces. That approach doesn't work so well for languages that don't match Java relatively closely (i.e. stack traces in Closure are, I understand, pretty horrific), but for our language it's turned out pretty well.

Or as Steve Yegge claims, the programming language doesn't matter nearly as much as the tools:

http://vimeo.com/16069687

Indeed, it's the overall "experience" (for lack of a better word) of programming in a particular language that matters. That's influenced by not just the syntax and structure of a language but also by all of the development tools, libraries, frameworks, documentation, and tutorials available, as well as the methods of working that those enable (i.e. REPL versus fast deployment, compilation steps required, ability to reload code on the fly, etc.).

    When it comes to debugging, nothing beats a few strategic print statements to inspect variables or a well-placed panic to obtain a stack trace.

I respectfully disagree with this statement.

Beyond simple issues a debugger is invaluable for following program flow and inspecting variable/memory states.

And why does "missing .. patience" mean you are more likely to use a debugger over a print statement?

In the last decade, I think I've pulled out a debugger only a handful of times. Apparently many people use them, but for me, understanding my code, writing tests, and tossing in some printfs has always been the way. I don't have a problem with debuggers, butfor me it is usually about having theories and testing them. This testing can happen in a debugger or in a print statement or in a test, but a test always seems like the best idea, and a print statement usually seems more straightforward to me than trying to stop and inspect my program while it is running.

Most of the time, for me, debuggers are only used on assembly code, which it is not as easy to insert a print statement or a hook.

You use this "my" word a lot. I personally use debuggers for debugging other people's code, code that's possibly decades old, that doesn't have enough modularity for good unit tests, and whose bugs in any case often only show up in complex multithreaded integration scenarios. GDB only acquired multiprocessing debugging support this year; to my mind it's pretty primitive.

How many people use debuggers like GDB day-to-day? I've found them useful when trapped in a corner, but typically I debug with the source in hand.

Anyone got any good debugging war stories?

I would assert that it is pure folly to attempt to build a non-trivial application in a compiled language without the assistance of a competent debugger. You simply cannot iterate quickly enough through the debugging loop of "Form theory" -> "Test theory" if you have to wait a minute for a build to complete each time. Unit tests help, but will never get you all the way there (good luck tracking down a leak with unit tests).

the repl is your friend even in compiled languages like haskell.

A proper REPL can do a lot of the same stuff you'd use a debugger for, and a whole lot more. With a nice REPL you'll do just fine without a debugger.

Why not use a REPL and a good debugger? It's a nice combination.

I consider myself a "competent debugger". ;-)

But more seriously: one of Go's selling points is fast compilation times. Even for large projects compilation is mostly I/O bound, which typically means sub-second compiles.

The Plan9 debugger, ACID is awesome, even in Unix.

http://swtch.com/plan9port/man/man1/acid.html

You can debug a kernel on a remote machine with a different architecture.

Shame that we've got to go back to the dark ages of GDB for Go.

We have plans to build a more fully-featured, Go-centric compiler (and there's the beginnings of one in the source tree under pkg/exp/ogle), but we haven't had the time to get stuck into it yet.

I've always used debuggers as a faster form of print statements. It faster to inspect several values using the debugger than it is to write and then delete a bunch of print statements.

However print statements become my go-to tool when debugging multithreaded code.

Reply on news.ycombinator.com