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?
There was a time when self-hosting your language made sense.
I did notice that you did not identify the system which can run a C compiler but cannot run a C++ compiler.