4 ms·

Sorry for this unrelated question. I am not very familiar with Go ecosystems. I have one question why there is not official debugger for Go? P.S. I am familiar

by 0xFFC 9y ago

Sorry for this unrelated question. I am not very familiar with Go ecosystems. I have one question why there is not official debugger for Go? P.S. I am familiar with delve. I am looking for official debugger support.

cdoxsey 9y ago
Part of the reason has to do with Go's original primary use case: a server handling thousands of requests. In that environment a traditional debugger, at least in my experience, isn't super useful, because it models a single-stepped workflow but the program is massively concurrent. (also pausing a production app is probably a bad idea) The kinds of bugs you run into are different and harder to track down, so Go has invested resources into some of those problems (for example the race detector, and automatic detection of concurrent map misuse) and you tend to rely on logging, profiling, tracing and stats to solve bugs. I think there are plans to make an official debugger it just hasn't been prioritized.
- konart 9y ago
  >In that environment a traditional debugger, at least in my experience, isn't super useful, because it models a single-stepped I'm pretty sure the question was about debugger to be used during development.
- joeshaw 9y ago
  > I think there are plans to make an official debugger it just hasn't been prioritized. There was a nascent project inside the Go team a couple of years ago (called ergo I think?) but I believe it was shelved in favor of Delve, which was much further along. It's probably safe at this point to consider Delve the de facto standard Go debugger.
  - deleted 9y ago
    [deleted]
Nvorzula 9y ago
On the whole I am very happy with Go, but this did bite me recently. We're using the X509 package which is returning an error on a handful of CA certificates due to characters that are not technically allowed in an ASN.1 PrintableString field (E.G `&`). Sure, fine, we've already forked the package so it's easy to make the change to be more lenient. Except errors don't contain any information about the origin of the error in source code, so it's been down to painful debugging and source code digging to find where this check is being made. If anyone has a less painful way to do this, please halp.

by 0xFFC 9y ago

cdoxsey 9y ago

Part of the reason has to do with Go's original primary use case: a server handling thousands of requests. In that environment a traditional debugger, at least in my experience, isn't super useful, because it models a single-stepped workflow but the program is massively concurrent. (also pausing a production app is probably a bad idea) The kinds of bugs you run into are different and harder to track down, so Go has invested resources into some of those problems (for example the race detector, and automatic detection of concurrent map misuse) and you tend to rely on logging, profiling, tracing and stats to solve bugs. I think there are plans to make an official debugger it just hasn't been prioritized.

konart 9y ago
>In that environment a traditional debugger, at least in my experience, isn't super useful, because it models a single-stepped I'm pretty sure the question was about debugger to be used during development.
joeshaw 9y ago
> I think there are plans to make an official debugger it just hasn't been prioritized. There was a nascent project inside the Go team a couple of years ago (called ergo I think?) but I believe it was shelved in favor of Delve, which was much further along. It's probably safe at this point to consider Delve the de facto standard Go debugger.
- deleted 9y ago
  [deleted]

Nvorzula 9y ago

On the whole I am very happy with Go, but this did bite me recently. We're using the X509 package which is returning an error on a handful of CA certificates due to characters that are not technically allowed in an ASN.1 PrintableString field (E.G `&`). Sure, fine, we've already forked the package so it's easy to make the change to be more lenient. Except errors don't contain any information about the origin of the error in source code, so it's been down to painful debugging and source code digging to find where this check is being made. If anyone has a less painful way to do this, please halp.