[Request] Official golang debugger

[Sotirios Mantziaris]

Hi,

with the lack of a official debugger, i  am using delve.

It is very nice and get the work done mostly, needs little or a lot of polishing.

Is there any plan to provide a official debugger which will be distributed with the releases?

Maybe delve could make it as the official one?

Do not get me wrong, delve is fantastic. Kudos to @derekparker and the contibutors for delve.

[Florin Pățan]

Delve is the one towards which the community rally since gdb, still, doesn't play nice with goroutines. So, for all intents and purposes, delve is the official debugger and the Go Team and Delve Team do work together to give us a better debugging experience. But sometimes the problems that need to be fixed are just too hard to do so quickly.

[Sotirios Mantziaris]

Yes i know that, but i wonder if it is time to fully integrate delve in the go toolchain and ship it with every release like dep, which exists in another repository, but will be fullly integrated into the toolchain and the releases in some future version.

[Florin Pățan]

I hope not. Anything that ends up in the toolchain is slow to change and adapt to user needs. If I have a problem with delve today, I can post an issue, fix it and get the next version of delve az quick as a few hours. If it would be in the toolchain it could take up to six months to get it released.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/UY6pvL8qeIw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sotirios Mantziaris]

I do not know if the times you mentioned are indeed that long.

If it is true then you actually have a good argument.

[Dave Cheney]

If you reported an issue today, Nov 6, you could be waiting nearly 9 months to see a fix in the next released version of Go.

A project living outside the standard library has little going against it other than you have to compile it yourself.

[Sotirios Mantziaris]

would it not make sense them to keep dep out of the std toolchain to adapt faster to changes?

[Florin Pățan]

dep is not part of the toolchain.

[Sotirios Mantziaris]

https://github.com/golang/dep/wiki/Roadmap

The goal with dep is to be absorbed into the go toolchain. That's the path we're on, but it's up to the Go community - you! - to help us see it through.  

--

Kind Regards,

S. Mantziaris

[Florin Pățan]

For that tool, which is not the subject of this thread, the maintainers are willing to pay the price of inclusion in the toolchain.

As I stated in my original reply,I would hope we don't have to pay the same price for the debugger.

I don't understand why anyone thinks that inclusion in the toolchain, as the toolchain is today is a good idea. The toolchain/standard library is where all things stop evolving any any significant speed and stop being able to break compatibil in favor of stability. If we'd have a 3 months release cycle then this might be a different story.

However it's ultimately not up to me to decide but I believe that the more things we have outside of the toolchain / standard library, the better.

[Dave Cheney]

That statement is pretty aspirational. I think it is likely that the go tool could grow the ability to understand repository tags, but beyond that I wouldn’t bet on one specific tool.

[Sotirios Mantziaris]

Apart from the time it would take to make changes to a tool in the toolchain i could come up with a reason for that:

If a new feature gets added to go that would affect the debugger it would be tackled away as part of the release as opposed to wait for the final release and start implementing the new feature after the release.

As a example for the above could be the vendor support change that would be in the tool right away or the recent change to pprof not needing the binary to resolve symbols etc.

Some tools a so core and should be in the toolchain like dependency management, debuggers, compiler etc...

I had a hard time choosing a dependency management tool as they where so many of them. As soon dep was announced to be the standard tool, i switched immediately to it since this is not something i would like to thing when i write code, it is just tooling.

This is just my thought.

[Dave Cheney]

On Tuesday, 7 November 2017 22:29:29 UTC+11, Sotirios Mantziaris wrote:

Apart from the time it would take to make changes to a tool in the toolchain i could come up with a reason for that:

If a new feature gets added to go that would affect the debugger it would be tackled away as part of the release as opposed to wait for the final release and start implementing the new feature after the release.

Anyone can download tip and build it, it almost always builds.

 

As a example for the above could be the vendor support change that would be in the tool right away or the recent change to pprof not needing the binary to resolve symbols etc.

I don't think these are very compelling arguments

- vendoring is an illusion created by the go tool, the compiler is unaware of it.

- the pprof change affects the pprof files written by the profiler, it is unrelated to DWARF information written by the linker.

 

Some tools a so core and should be in the toolchain like dependency management, debuggers, compiler etc...

I had a hard time choosing a dependency management tool as they where so many of them. As soon dep was announced to be the standard tool, i switched immediately to it since this is not something i would like to thing when i write code, it is just tooling.

This is just my thought.

I'm on your side here, and my advice is do not yoke your debugging tool to the go tool release cycle. 

[Sotirios Mantziaris]

You both make good point to why that might have it's issues.

Taken into account the time mentioned it makes more sense to keep it separate and have it's own release cycle.

Thanks for your input.