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.
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.