I don't know. C is very close to the hardware, and it's pretty portable, too.
I'd suggest doing what some other languages do, and get yourself to the point where almost all of the code for Zig is written in Zig.
In other words, you'd first write a `microzig` that's written in C++, and microzig knows enough to make `minizig`, which knows enough to make the rest of zig. This is what Perl does, and I expect other languages do the same thing.
On the other hand, zig is supposed to be able to cross-compile really well, so maybe you can skip that: Have version 0.9.9 be the last version written in C++. Then, for version 1.0, re-write the entire toolchain in Zig, and use the 0.9.9 compiler to compile Zig 1.0. At that point you are in full dogfood mode.
Finally, since it's called Zig, I get to close with this sentence: "You have no chance to survive make your time."
It's an interesting phenomenon, specifically how processor companies (erm, Intel), who make "general purpose" CPUs, have clearly made trade offs to optimize for OSes that behave like UNIX or Windows varients!
Well, in fact, Intel and all the other major makers spend a huge amount of effort benchmarking important workloads. It isn't a decision to optimize for Unix or Windows, it is a decision to chase dollars. They will optimize processors for your favorite workload, too. Just demonstrate how many millions of dollars of business your workload represents, and create some sound benchmarks for it. Easy.
This seems to be changing. Hardware is trying to move closer to java -by adding support of GC, bounds checks, etc - something that won't help C programs as much.
Unfortunately, the C compiler devs didn't implement the bounds checking extensions of C11, etc. It would have been really nice to have a good checked C that was the standard.
> C is very close to the hardware, and it's pretty portable, too.
Here you seem to be suggesting that portability is good, but then...
> zig is supposed to be able to cross-compile really well, so maybe you can skip that
... you seem to be suggesting that this project should give up its (already existing!) portability. Without saying why.
In 2016, it's not clear at all why having having a compiled language be self-hosting should be considered a worthy goal. It's just a lot of busywork instead of simply using an existing toolchain. Certainly not the right thing to do from a software engineering point of view. Certainly not the right thing to do if you want portability. Certainly not the right thing to do if you want interoperability with existing sanitizers. Certainly not the right thing to do if you want powerful optimizations.
I'd agree that the frontend should probably be bootstrapped, at some point. But the whole toolchain? Just to avoid random HN commenters throwing "every self-respecting programming language is bootstrapped" at you? Nah.
I'd suggest doing what some other languages do, and get yourself to the point where almost all of the code for Zig is written in Zig.
In other words, you'd first write a `microzig` that's written in C++, and microzig knows enough to make `minizig`, which knows enough to make the rest of zig. This is what Perl does, and I expect other languages do the same thing.
On the other hand, zig is supposed to be able to cross-compile really well, so maybe you can skip that: Have version 0.9.9 be the last version written in C++. Then, for version 1.0, re-write the entire toolchain in Zig, and use the 0.9.9 compiler to compile Zig 1.0. At that point you are in full dogfood mode.
Finally, since it's called Zig, I get to close with this sentence: "You have no chance to survive make your time."