I am not sure it is comparable: the self-hosted compiler uses a different architecture [1].
(Also, you're replying to the primary author of Zig and presenter of that talk, if you weren't aware.)
https://docs.google.com/spreadsheets/d/14_ljFHGFXY5NhBhlfjgk...
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.
I think elaborating on this could make for a very interesting article. :-)
(I have a guess already at one item, which is MultiArrayList, something that kind of blew my mind when I first learned about it, and is in my opinion a very impressive testament to both the power and ease of use of Zig's approach to compile-time computation.)
https://github.com/ziglang/zig/blob/master/lib/std/multi_arr...
Zig's still got it beat handily in simplicity though -- I think what's really cool about Zig's idea of comp-time evaluation is you get something like the power of C++ with something like the simplicity of C.
This seems fairly significant to me and makes me wonder how this is possible with all the effort that has gone into optimizing C++
While zig can work use modern techniques without such issues
Which is used all over the world?
What's the difference between the stage2 and stage3 binary? Does stage1 produce different binaries for the same input compared to stage2/stage3?
* stage1 is when zig is built from C++ code[1] (the "bootstrap" compiler) using system C/C++ compiler toolchain.
* stage2 is when zig is built from Zig code[2] using stage1.
* stage3 is when zig is rebuilt from the same Zig code[2] using stage2.
Before today, zig would give you stage1 by default, and you could opt in to stage2 using `-fno-stage1`. After today, zig gives you stage3 by default, and you can opt in to stage1 using `-fstage1`.
In all three cases, LLVM is being used. Although Zig has started to fully self-host by providing backends that have no dependency on LLVM, none of these fully self-hosted backends are complete.
Why bother self-hosting? Because:
* Zig produces smaller, faster binaries than C++ that use less memory[4]. Case in point: the new self-hosted compiler is 1.5x faster than the C++ implementation and uses 3x less peak RAM.
* Development velocity in Zig is much faster than C++, and debugging is a breeze in comparison due to Zig being much safer than C++ and having better debug tooling. Similarly, comptime features let us add more assertions and debug checks that are not possible in C++.
* Zig compiles much faster than C++.
* Zig cross compiles better than C++ making it easier to create builds of the compiler for every target.
* The self-hosted compiler does not need a softfloat library dependency to support f16 or f128 operations.
* Zig's std lib data structures are incredibly useful, especially compared to the C++ STL.
There are still many known bugs; not every project will be able to upgrade immediately. See the full upgrade guide [3] for help deciding when and how to upgrade.
[1]: https://github.com/ziglang/zig/tree/master/src/stage1
[2]: https://github.com/ziglang/zig/tree/master/src
[3]: https://github.com/ziglang/zig/wiki/Self-Hosted-Compiler-Upg...
[4]: https://media.handmade-seattle.com/practical-data-oriented-d...