WASM allows them to bootstrap Zig compiler on completely foreign systems that only have a C compiler. This solves the chicken-and-egg dilemma that occurs when one wants to use a language under development to develop the language itself.
It's not about code size or efficiency. They are talking about the ability to use the latest versions of Zig for further development of the Zig compiler. This improves and speeds up the compiler development cycle by removing the limitations imposed by the bootstrap process.
Once, good compilers were rare and expensive, and coding a compiler in your new language proved to people that it was adequate to implement a compiler.
Nowadays good compilers for everything are common and free. Coding a compiler for your language in your language demonstrates only that you could afford to waste the time, because literally every language suffices to code a compiler in.
> Coding a compiler for your language in your language demonstrates only that you could afford to waste the time
You seem to be presupposing this is true, but this is a pretty controversial claim. Do you have any justification for it?
As other people in this thread have mentioned, there are other benefits to programming your compiler using your own programming language:
- You learn your language (and its rough edges) first hand
- You can try out & experiment with new language features
- The authors of Zig clearly think zig is better to use than C++. (If not, why would they bother inventing zig?). It makes sense that if you think Zig is a better language than C++, you'd want to write your compiler in Zig and not C++.
Lots of compiler authors (you know, the people who get a vote) disagree with you on this: Clang, VC++, etc are written in C++. Rustc is written in rust. The main zig compiler is written in zig. DMD is written in D. And so on.
And anyway, whats so great about C++ that it would make a good language to write compilers in in the first place? Why shouldn't I write my compiler in plain C, or Rust, or Zig, or Go, or whatever strikes my fancy?
You seem to miss, again, that there was already a complete Zig compiler coded in C++. Coding another one, in Zig, was strictly extra work.
People can write whatever they like in whatever language they like. We need not invent spurious reasons. Surely the creator of Zig already knows Zig; coding a compiler in it teaches him nothing new. He could experiment with draft language features in any program at all: nothing about the task of compiling Zig code is better for that purpose than myriad others.
Obviously the second compiler for Zig was done because the author wanted to. But having done so demonstrates nothing meaningful about Zig. It only tells us its author took time to code what we know, with utter certainty, was a strictly unnecessary program, instead of doing something actually useful.
Doing stuff that is not useful is allowed. We need not pretend otherwise, or make up excuses.
The new compiler was not a direct port of the old one. It explored fundamentally different design decisions. The new compiler is a better piece of engineering than the old one. It wasn't strictly extra work. In order to achieve our current feature set and performance characteristics, such changes would have either needed to be done on the old codebase or the new one. It's a pretty easy argument to make that the increased developer velocity from using Zig landed us further along, by this time today, than it would have if we would have invested in the C++ codebase instead. You can argue against that particular claim but what you can't meaningfully do is call the efforts useless.
You found a way to make coding a second compiler useful.
But it remains manifestly unnecessary, because everything done in the "second system" (cf.) could have been done with less effort by altering the first. Achieving it demonstrated nothing more about Zig than that there were people willing to take time to do it.
Arguments from "velocity" have, in particular, always been unconvincing. People code faster in a language they like, and credit the language, but other people are equally quick in other languages.
"Bother"? Motivation is interesting. Getting all excited over what language a compiler is coded in, far beyond any actually, independently useful program, is objectively weird.
C got its legs from a whole OS coded in it. The compiler was very incidental. I don't have any programs in Rust on my SSD. I have one Haskell program: pandoc. I have no Java, C#, Scala, Clojure, Kotlin, or Erlang programs. I have one in Dart I don't use anymore.
A substantial, useful program in Zig that would be too much work to re-implement in a mature language would do orders of magnitude more for Zig than a second compiler. Maybe a collection of pipewire modules, or matrix gateways?
Perceptions of velocity by language advocates have very, very little to do with actual velocity in industrial settings. The latter is what matters, but is actual work to measure. Anybody measuring seems not to be publishing.
We’re actually looking to support Zig as an authoring language for user generated content for Third Room - the spatial collaboration platform for Matrix. Not sure this would be a killer app like a Matrix server or gateway or something, but could help a bunch. https://thenewstack.io/third-room-teases-user-generated-cont... has more details.
Doesn't seem like it needs much support, as such, being able to use ".h" files directly.
You would not want anything that must be depended upon coded in it, in case it fizzles like almost all languages do, but that leaves huge scope for valued additions on top.
> You seem to miss, again, that there was already a complete Zig compiler coded in C++.
No, there wasn't. They had a half-implemented compiler in C++ which implemented just enough features to compile the proper zig compiler. It didn't have feature parity.
> Obviously the second compiler for Zig was done because the author wanted to. It only tells us its author took time to code ... a strictly unnecessary program, instead of doing something actually useful.
You think dogfooding isn't useful? Wow, thats a really bold claim. I know legions of product engineers who would line up to disagree with you. Dogfooding is tremendously useful.
Failing to dogfood creates an empathy gap with your audience. (You don't understand your own work as well!). If you don't immerse yourself in your own creative output (eg, rust developers writing rust code, musicians listening to their own music, etc) then your output is usually lower quality because you aren't training your taste. How do you know what design decisions are good and bad, or what to focus on, if you aren't using your own output?
And not dogfooding is a motivation killer on passion projects. Why build something for fun when you don't even get to enjoy the fruits of your own labor?
I suppose Andrew Kelly could have a second medium-to-large project that he uses Zig for in order to understand his users. And he could go back and forth between coding Zig in C++ and coding that other project in Zig. (I think Jonathan Blow does that with Jai.) But that sounds like a huge waste of effort when he could just be spending all his time writing the zig compiler in zig, which is what he wants to be doing anyway.
I'm not making a technical argument. V8 seems to work fine despite being written entirely in C++. But V8 is just programming to a spec someone else wrote. Programming language specs don't come out fully formed. They need to be thought through, experimented with and obsessively argued over.
How would Zig become a good language if the team that invents it doesn't even programming in it themselves?
This is about the language the compiler itself is coded in. It would be absurd to try to run a compiler on your ESP microcontroller just because that is where the program you are compiling is supposed to run. (That does not stop Forth fans, of course.)
People do often run compilers on RaspPis and the like (though rarely for any good reason), but those compilers are most often coded in C++, whatever the language it is compiling, just like Zig's original compiler.
Most of the Rust compiler is in C++, and they have no plan to change that.
> Most of the Rust compiler is in C++, and they have no plan to change that.
What? I just went and searched the Rust compiler, and the only C++ code to speak of was LLVM itself, and a thin wrapper around LLVM to provide a C API. Which is pretty much the same state that Zig is in right now. (Although in Zig's case, LLVM is optional)
Yeah, it's a lot of C++ that the Rust compiler relies on, but I don't think most people would really compare things like that.
RasPis and the like are literally more powerful than your typical desktop PC 20 years ago. They can run all kinds of compilers, interpreters etc just fine, including those that are bootstrapped.
Real embedded is more challenging, but even then... DOS ran on 640 Kb of RAM for userspace, and it had C and even C++ (albeit pre-ISO) compilers, and many embedded platforms these days come with something comparable. Forth is really only necessary if you want to bootstrap on really low-memory stuff.
That's exactly what i said, they regret writing their compiler in C++, and are too lazy to do a proper and optimized C rewrite, hence they go with WASM to then generate C code
Reason why it still is running poorly, because it is the same implementation, just went with optimized code gen steps, making the source non human readable
Just so you know, the reason your comment isn't productive (especially with the culture of this site) is that your are creating a projection of the developer's mind and motivations, that most likely isn't true (I doubt they are lazy, and I also doubt there is regrets there too).
It has generated a healthy discussion, that helped me get more insight on the matter, and will help future readers get a detailed insight on the matter too
Not everyone is born with knowledge, we learn by igniting discussions
It's not about code size or efficiency. They are talking about the ability to use the latest versions of Zig for further development of the Zig compiler. This improves and speeds up the compiler development cycle by removing the limitations imposed by the bootstrap process.