Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support Debugging #21

pzurek opened this Issue Apr 10, 2014 · 21 comments


None yet
9 participants

pzurek commented Apr 10, 2014

Breakpoints, code stepping, the works...
That would be awesome, please.

From @joefitzgerald on Reddit:

Yep, it's possible - we'd need to integrate with GDB and also provide the ability to launch a go program, a test, or all tests


joefitzgerald commented Apr 11, 2014

"The state of gdb support"

This is interesting for a few reasons:

  1. The golang team do not believe gdb is the future of debugging for go
  2. There is no proposed alternative

At first glance, I think this prioritizes gocode support above gdb support. But more fundamentally, it makes me question whether it's worth expending the time integrating gdb at all.

I think we all agree that it would be very much desirable to have debugging, the ability to set breakpoints, inspect locals and watches, and step through code. On the one hand, the lack of it forces some positive behavior (e.g. more tests!), but on the other hand it can create negative behavior (fmt.Println(everything)).

@joefitzgerald joefitzgerald added this to the 3.0 milestone Apr 11, 2014


joefitzgerald commented Apr 11, 2014

https://code.google.com/p/go/issues/detail?id=7471 is also worth a read, and raises the possibility for lldb to be a path forward. Regardless, there's still no decision or clear direction from the team.

pzurek commented Apr 11, 2014

I would say gocode definitely before this. For gocode there is one clear path.
The debugger support seems much less defined at the moment. I personally had my hopes raised by renewed activity in the Ogle repo: https://code.google.com/p/ogle/source/list.

@joefitzgerald joefitzgerald changed the title from Debugger support to Debugger Support Apr 28, 2014


joefitzgerald commented Apr 28, 2014

Update post-gophercon. There is no clarity on this issue. gdb support is likely to wane over time, and I'm not aware of any concrete plans / a path forward with a specific tool.

If someone wants to spend the time to integrate gdb, I will accept a good quality contribution – but I am unlikely to invest the time to do this myself.

is a debugger not real coding? or do the golang cognoscenti never create bugs in their code?

wow. I'm somewhat stumped.


joefitzgerald commented May 21, 2014

I hope I am not considered cognoscenti 😉. The takeaway from my last comment should be "Joe isn't sure of the direction the golang core team wants to take with regard to debugging, so is hesitant to invest time integrating a specific debugger" rather than "Joe doesn't like debuggers".

I see great value in debuggers, and spend a lot of time in one debugging this very package 😬.

Edit: Also, once we've drained all the other issues in the backlog, if this is the only one remaining I'm sure we'll end up working on it. Autocomplete and others are just higher priority now.

How about integrating hopwatch ? It is hardly a debugger but you can set breakpoints to inspect stack and program state. It requires modification of your source but the Atom package might help in organizing this. https://github.com/emicklei/hopwatch

nkev commented Oct 21, 2014

There seem to be a few debuggers popping up by people tired of waiting for the GO team:


The first one seems serious and active. I wonder if it can be integrated into Atom as a GUI debugger?


joefitzgerald commented Nov 4, 2014

Just to reiterate: I'm always open to possibilities in this issue. If someone wants to put together a pull request for this functionality I would gladly accept it.

@joefitzgerald joefitzgerald removed the question label Nov 4, 2014

@joefitzgerald joefitzgerald added this to the Unscheduled milestone Nov 4, 2014

nkev commented Nov 4, 2014

I think #2 Gocode integration is more pressing...


joefitzgerald commented Nov 4, 2014

Yes, it keeps coming up over and over in forums like Reddit, Hacker News, etc. Lack of gocode is causing some people to go back to other tools.

@joefitzgerald joefitzgerald modified the milestones: 4.0, Unscheduled Apr 20, 2015


joefitzgerald commented Apr 20, 2015

I would like to see this done via an integration with godebug. If anyone would like to contribute I would gladly accept a PR for this, otherwise I will get to it after I have cleared the current backlog of PRs.

@joefitzgerald joefitzgerald changed the title from Debugger Support to Support Debugging Via godebug Apr 20, 2015

nkev commented Apr 20, 2015

@joefitzgerald https://github.com/derekparker/delve is all the rage at the moment. It even has an API for IDE's now. The author, Derek Parker is speaking (about it I presume) at Gophercon this year.

@pzurek pzurek changed the title from Support Debugging Via godebug to Support Debugging Apr 21, 2015

solher commented Jul 9, 2015

The Delve IDE integration problem is closed now derekparker/delve#88. It seems like an IntelliJ plugin is on the way go-lang-plugin-org/go-lang-idea-plugin#1252. That would be amazing to have it in go-plus too.

nkev commented Nov 18, 2015

@joefitzgerald I've been working with the Delve debugger in the IntelliJ plugin and unfortunately it's not what we hoped it to be. It's too slow when stepping through code - not really a Visual Studio - like experience. Maybe your original idea of godebug integration was better... i.e. a go-plus "debug" mode that inserts Atom debug-lane breakpoints into the code and compiles to an executable with a "_debug" suffix, e.g. projectname_debug. See the image in the Atom PHP debugger to see what I mean.

@nkev, have you talked to delve about the slowness? I havent seen any issues relating to it.

nkev commented Feb 23, 2016

No, I thought it might be my machine or my Delve installation, etc.
However, on the same machine Delve works great in Visual Studio Code.


joefitzgerald commented Apr 1, 2016

There's already a PR open for this.


joefitzgerald commented Aug 20, 2016

This shipped in v4.2.0 of go-plus :shipit:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment