I agree with this sentiment, at the same time, there’s nothing stopping the next debugger from being written in Zig. It could support everything which GDB and LLDB cover already, as well as providing better hooks for languages those two aren’t doing as good a job with.
This would be many human-years of labor, of course, and just patching and extending LLDB might be easier. But a debugger is exactly the kind of low-level system-oriented programming which Zig excels at. Sometimes the right thing to do is start fresh, with a system which doesn’t fundamentally assume it will be looking at either C or C++, an architecture which lets languages register specifics in an extensible way which covers bases for the next language as well.
LLVM itself was Chris Lattner realizing that it would be more practical to re-engineer the entire C/C++ compilation chain from end to end, rather than try to get GCC to work the way he thought it should. There’s precedent.
Visual Studio is not dedicated or specific to C#. It is a general IDE that supports many languages through extensions. This extensibility permeates all the functions of the IDE, from syntax highlighting to the project system, to the debugger. Anyone can add language support through the extensibility model. In its history, it has had support for C/C++, Pascal, Fortran, Cobol, Java, typescript, javascript, and others.
I don’t have a good debugging strategy for debugging Zig on Windows (particularly since I dislike VSCode very much) but on Linux I just use gdb. It’s able to work with it quite well from my experience. But dedicated support in debuggers would always be better.
Wow, the RAD debugger works much better than what I expected, especially for an alpha project. Memory, registers, breakpoints – it’s definitely a good start.