3 ms·

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

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]