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. On Tue, Nov 7, 2017 at 11:33 AM Florin Pățan <florinpa...@gmail.com> wrote: > 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. > > On Tue, 7 Nov 2017, 09:19 Sotirios Mantziaris, <smantzia...@gmail.com> > wrote: > >> 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. >> >> On Tue, Nov 7, 2017 at 11:16 AM Florin Pățan <florinpa...@gmail.com> >> wrote: >> >>> dep is not part of the toolchain. >>> >>> On Tue, 7 Nov 2017, 08:38 Sotirios Mantziaris, <smantzia...@gmail.com> >>> wrote: >>> >>>> would it not make sense them to keep dep out of the std toolchain to >>>> adapt faster to changes? >>>> >>>> On Tuesday, November 7, 2017 at 9:31:01 AM UTC+2, Dave Cheney wrote: >>>>> >>>>> 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. >>>>> >>>>> On Tuesday, 7 November 2017 18:28:09 UTC+11, Sotirios Mantziaris wrote: >>>>>> >>>>>> I do not know if the times you mentioned are indeed that long. >>>>>> If it is true then you actually have a good argument. >>>>>> >>>>>> On Tuesday, November 7, 2017 at 9:20:08 AM UTC+2, Florin Pățan wrote: >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> On Tue, 7 Nov 2017, 07:04 Sotirios Mantziaris, <smant...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> On Tuesday, November 7, 2017 at 1:38:27 AM UTC+2, Florin Pățan >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> 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. >>>>>>>> >>>>>>>> -- >>>>>>>> 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. >>>>>>>> >>>>>>> -- >>>> 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+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> Kind Regards, >> >> S. Mantziaris >> > -- Kind Regards, S. Mantziaris -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
