Live data from Hacker News

Zig is now self–hosted by default

github.com

61–70 of 115 posts

Re: Zig is now self–hosted by default

#61
post #44

I never understood why "self-hosting" is considered a good thing. Sure, the compiler developers can write in their favorite language and I guess it means the language is stable enough to be used in a complex project; however requiring an (older) compiler to build the compiler seems a significant complication for software distributions. You either have to set up an ever increasing chain of compilers, as the complexity…

There's a third option that you missed which is what Zig does. It has a "bootstrap" compiler, written in C, which is kept in sync with the self-hosted compiler. Features are implemented twice, once in the bootstrap compiler, once in the self-hosted compiler. So the build process involves a fixed set of steps - stage1, stage2, stage3 - and the chain never grows more than this. No pre-existing binaries are required.

Re: Zig is now self–hosted by default

#62

To clarify what this means, since things can get confusing with subtle differences in wordings: * 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 st…

> 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.

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...

Re: Zig is now self–hosted by default

#63
post #11

Earlier quoted context omitted.

Thanks for the context! What's the difference between the stage2 and stage3 binary? Does stage1 produce different binaries for the same input compared to stage2/stage3?

Ideally there should be no difference and building stage 3 is basically a sanity check to ensure the compiler is working correctly.

Not quite - what you said is true for a hypothetical "stage4" however there is a distinct difference between stage2 and stage3. While they are built from the same source code, and therefore have the same logic, they are lowered by different backends, meaning they will have potentially drastically different performance characteristics depending on the differences between the stage1 and stage2 backend, respectively.

Related: https://github.com/ziglang/zig/issues/12183

Re: Zig is now self–hosted by default

#65
post #44

I never understood why "self-hosting" is considered a good thing. Sure, the compiler developers can write in their favorite language and I guess it means the language is stable enough to be used in a complex project; however requiring an (older) compiler to build the compiler seems a significant complication for software distributions. You either have to set up an ever increasing chain of compilers, as the complexity…

Because a large motivation of developing a new language is wanting to program in that new language. Being forced to keep programming in C can become very frustrating.

Although if you're Jonathan Blow you can stream yourself writing C++ and ranting about how terrible C++ is, while implementing your new Jai language.

[I watched a few hours of Jon doing this, but annoyingly I can't find a recording of Jon actually finding and fixing the subtle Heisenbug he realises during those hours must be in his Jai code - he resolves to investigate "later" and I can't find "later". I think this would be insightful to watch because this is exactly the sort of bug Jon says he doesn't have much trouble with in his C++ and so doesn't need to prevent in Jai... so if it's five minutes to fix that shows Jon is correct, if it's hours of difficult searching or eventually was resolved by just unrelated changes to the code not so much]

Re: Zig is now self–hosted by default

#66
post #44

I never understood why "self-hosting" is considered a good thing. Sure, the compiler developers can write in their favorite language and I guess it means the language is stable enough to be used in a complex project; however requiring an (older) compiler to build the compiler seems a significant complication for software distributions. You either have to set up an ever increasing chain of compilers, as the complexity…

Once upon a time C was bootstrapped as well.

A great outcome of bootstrapped compilers is that most contributors can use the language they known instead of two, and better it kills the myth that C is the only game in town for writing compilers.

Re: Zig is now self–hosted by default

#67
post #39

Earlier quoted context omitted.

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

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.

Re: Zig is now self–hosted by default

#68
post #44

I never understood why "self-hosting" is considered a good thing. Sure, the compiler developers can write in their favorite language and I guess it means the language is stable enough to be used in a complex project; however requiring an (older) compiler to build the compiler seems a significant complication for software distributions. You either have to set up an ever increasing chain of compilers, as the complexity…

Virgil is completely self-hosted. The git repository just has stable binaries checked in that are updated periodically (15-20 times over the past 12 years or so). It bootstrapped first from an interpreter written in Java, which is long obsolete.

Because of this, Virgil has no dependencies on other compilers or languages, other than for testing (bash and a little C).

Re: Zig is now self–hosted by default

#69
post #44

I never understood why "self-hosting" is considered a good thing. Sure, the compiler developers can write in their favorite language and I guess it means the language is stable enough to be used in a complex project; however requiring an (older) compiler to build the compiler seems a significant complication for software distributions. You either have to set up an ever increasing chain of compilers, as the complexity…

There's a third option that you missed which is what Zig does. It has a "bootstrap" compiler, written in C, which is kept in sync with the self-hosted compiler. Features are implemented twice, once in the bootstrap compiler, once in the self-hosted compiler. So the build process involves a fixed set of steps - stage1, stage2, stage3 - and the chain never grows more than this. No pre-existing binaries are required.

[deleted]

Re: Zig is now self–hosted by default

#70
post #44

I never understood why "self-hosting" is considered a good thing. Sure, the compiler developers can write in their favorite language and I guess it means the language is stable enough to be used in a complex project; however requiring an (older) compiler to build the compiler seems a significant complication for software distributions. You either have to set up an ever increasing chain of compilers, as the complexity…

There's a third option that you missed which is what Zig does. It has a "bootstrap" compiler, written in C, which is kept in sync with the self-hosted compiler. Features are implemented twice, once in the bootstrap compiler, once in the self-hosted compiler. So the build process involves a fixed set of steps - stage1, stage2, stage3 - and the chain never grows more than this. No pre-existing binaries are required.

> No pre-existing binaries are required.

Except for of course a c compiler.

Post reply on HN