

Debugging Go code (a status report) - abraham
http://blog.golang.org/2010/11/debugging-go-code-status-report.html

======
akeefer
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).

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

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

------
hartror

        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?

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

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

------
enneff
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?

~~~
abhijitr
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).

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

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

~~~
arethuza
Why not use a REPL _and_ a good debugger? It's a nice combination.

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

