Eh, more particularly "the state of Zig debuggers and gdb in particular on NixOS Linux" - the author isn't wrong to want things to work, of course, but the author isn't using the most boring environment either.
* gdb works on zig code, so it isn't unreasonable to expect gdb frontends to also work * being on nixos might explain crashes or failing to start, but it's hard to imagine how it could be responsible for various gdb frontends not being able to set breakpoints, run to the correct line or render a pointer to an array of bytes, especially when those same features work fine in gdb * it also doesn't explain why the memory view in most frontends was buggy or didn't work at all * I also tried lldb, whose gui I couldn't operate at all, and code-lldb, whose breakage might actually be nix-related since I had to patch a binary (but the error message was complaining about invalid utf8...)
I'm also happy to try non-gdb/lldb debuggers if you have any suggestions.
I know Solaris has its own debugger(s?), and rr looks really useful, but I haven't worked on a platform that could run either.
As they say typically in the license conditions: This software comes with absolutely no warranty.
Nothing that's not tested in every release (better in every CI build) can be assumed to work. How much of a standard boring Linux distro is written in zig? (That's an honest question, not a justification or even a defense to ship broken software.)
So yes, the headline is most likely misleading: It should be "The state of debugging zig binaries in NixOS." I expect that debugging a C binary on OpenSUSE[1] would give different results.
[1] I picked OpenSUSE here because installing library source is very easy and to my limited experience gdb just finds it. I haven't used OpenSUSE for a while. I have never used NixOS, so no clue whether that would rank above or below average.
How are you able to make that judgement?