Because the people who need it most don't actually need it that much, otherwise they would have written it. When I debug most Go programs, I'm doing high-level debugging. A debugger is a sharp tool. For 90% of my debugging task I don't need scalpels, I need tools that can provide a holistic view of a system from above. I use DTrace for that.

When I actually use a debugger, it's low-level work; I either debug the runtime or the compiler and I use assembly. Mdb/gdb/acid is perfectly adequate for that. A debugger with special Go support is of no use to me.

That being said, a Go debugger is on the table.

Yes, on the Internet everyone wants everything, generics, IDE, higher order metaprogramming, etc. In the end, people who actually implement any tool, feature, or process are doing it only because it helps their concrete work in a very practical way. Yes, a debugger would be useful, but almost anything is useful in isolation. So far, the people who do the work didn't write a debugger, because even if it might have been useful to some, it would have been a net loss for their particular problem they were solving at that particular time, because of the additional effort.

I'm writing the arm64 compiler. I wrote a CPU simulator and a debugger. It's a very low-level tool and very useful to me at this particular stage in the port. Even though it took time to write it, it saves time overall. It's useless for 99.99% of other Go programmers.

Please could you elaborate on the arm64 compiler. Is there a repo somewhere, etc?

No sorry, the work is relatively too early for that yet. Significant progress has been made, but a lot is still to be done. The Plan 9 C compiler included with Go works well but the Go compiler not yet. I'm pushing for inclusion in 1.4.

Forgive me for asking (not usually a programmer of anything that goes directly to machine code), but is single step debugging as relevant for a language such as Go which has far fewer ambiguities and undefined behaviour? Isn't single step debugging used precisely because C/C++ code generation is less predictable than Go's?

No. It's really useful to be able to just look at what's happening; it lets you do binary search to figure out where your assumptions are wrong, rather than having to verify every individual step. I use Scala which can provide much stronger static guarantees than Go, but a debugger is still very valuable.

some discussion is available here: https://groups.google.com/forum/#!topic/golang-dev/UiVP6F-9-...