Here are some features of Zig that make debugging much easier than C++:

* safety checks (equivalent to UBSAN) when triggered, print stack traces that include source code lines and point to the relevant line/column

* one of the safety checks is using the wrong field of an untagged union. This one is so underappreciated. Wrong union field access costs so much time to debug in C++ but it is a breeze in zig, you get a crash explaining the problem with a stack trace immediately, not a corrupt value that causes problems down the road. untagged unions are core part of the strategy that makes zig fast & have a small memory footprint.

* valgrind client request integration[1]. valgrind "just works" better with Zig than C/C++ because zig emits communicates more information about memory regions that are "undefined".

* error return tracing [2]

* segfaults print stack traces

* std.debug has features to collect stack traces in a compact manner and then dump them at a relevant time [3]

* std.heap.GeneralPurposeAllocator detects leaks and prevents memory corruption from Use-After-Free/Double-Free, making debugging easier

[1]: https://valgrind.org/docs/manual/manual-core-adv.html#manual...

[2]: https://ziglang.org/documentation/master/#Error-Return-Trace...

[3]: https://github.com/ziglang/zig/blob/4a98385b0aa3808ab05a1ebf...

Thanks!

Maybe the runtime safety in debug builds? Like for out of bounds, int overflows, etc. In my zig projects those checks have saved me from using a debugger or valgrind in many cases.

I guess I don't call runtime safety features "debug tooling"? But maybe that's the disconnect here

I think it's funny that I got downvoted for this! For full clarity: I wasn't suggesting that they _shouldn't_ be called debug tooling, just that it's not what I would call that class of feature, and it seems that other people do call it that.

I'd call tools like ASAN and friends debug tooling. I'm not sure if zig has tooling that doesn't have an analogue in the c++ world, but having them built in to the compiler by default is a notable feature.

Right, defaults matter. The fact sanitizers exist is much less of a game changer than the default behaviour being sanitized.

Because C++ defaults are notoriously all wrong, in programming language design you could usually do worse than consider, "Is there an alternative to what C++ does here by default?" and if there is one, choose that alternative as your default because it's more likely to be correct.

Sometimes C++ helps you out, it might have a keyword "do_it_right" and you can just default to that, if you feel people might want the C++ default behaviour, feel free to reserve "do_it_wrong" in case people wanted that, but in many cases they will never ask you to implement the C++ behaviour because it's just wrong. Examples: "const" in C++ doesn't mean "constant" it means "immutable", so, make immutable your default and offer "mutable" as the option. "explicit" in C++ makes constructors need an explicit cast to be used for conversion, once again of course you want that by default but feel free to reserve "implicit" in case some people are sure they need the C++ behaviour.

C++ frameworks pre-standard used to have better defaults, unfortunately there a majority of people voting that would rather have the wrong defaults, and so here we are, and given how ISO works it won't change.

Those that care know where the knobs are to re-enable those proper defaults, given that for some domains, C++ is going to stay around for a while, regardless of the alternatives.