Go debugger using delve for Atom | Hacker News Reader

Go debugger using delve for Atom

atom.io

52 pointsnnx15 comments

I'd very much like to use a debugger with my Go code but the two initiatives I've seen both require installing delve locally and it's a big pain in the ass. The official instructions for OSX begin with "Make a self signed certificate", which they then break down into 14 separate steps.

I wonder how hard it would be to make a delve server and install it on a Docker instance that could talk back to Atom/Sublime/VSCode.

Honestly, comparing the choice of mucking with code signing on OS X and having to deploy, run, and debug my app through Docker, I would just learn to sign code.

I do think it's weird that more debuggers don't come as signed binaries--gdb requires you do similar things and it all goes back to OS X's requirement that processes which take control of other processes have to be running signed binaries.

You can use homebrew with this command:

brew install steeve/delve/delve [--HEAD]

Just tried this on a new setup and it works fantastically. It did all the cert mucking for me.

Precompiled binaries for OS X are coming: https://github.com/derekparker/delve/issues/494

This looks nice. Is there something similar for Python?

Yea, VS Code.

I found this https://atom.io/packages/python-debugger

Cool, last time I checked (~5 months ago) there was no python debugger for Atom. I'll try it right now.

Interesting, how Go users struggle with basic things nowadays, whereas it was considered as granted e.g. in QBasic in early 90s...

No need to troll. GDB has worked (to a limited degree) on Go binaries for years, but has never really understood some of its features; Delve is a newer debugger that's specifically targeted to Go.

I thought the preferred way of degugging Go code was through LLDB, but that support for this requires a very recent and you may have to build the LLVM toolchain from source, until it gets packaged up in a new release?

Are all these debuggers working in parallell on reimplementing the same features? That seems like such a wasted effort.

Do you realize, after the first sentence, you're basically saying the same thing which I've pointed out as an interesting fact?

Nobody is "struggling" with debugging Go programs in the way you were implying. You seemed to be deliberately trying to antagonise, disguising it behind "Interesting, ...".

You're overthinking it. Also, "interesting" is most neutral I believe. Alternatives: "fun" - too sarcastic; "sadly" - too dramatic.

GDB work with Go ... until you use concurrency and it doesn't. Also Go tends to print useless error messages when an error is fatal so it doesn't really help. Go needs to be able to compile code for debugging purposes.

Reply on news.ycombinator.com