> having better debug tooling
What debug tooling are you referring to? It seems like people just use lldb to debug zig programs?
I'm honestly interested, and searching doesn't turn up good tools as far as I can tell.
What debug tooling are you referring to? It seems like people just use lldb to debug zig programs?
I'm honestly interested, and searching doesn't turn up good tools as far as I can tell.
* 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...
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.
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.