4 ms·

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 wha

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.

AndyKelley 4y ago
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.
- moloch-hai 4y ago
  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.
  - josephg 4y ago
    If that’s true, it sounds like a strong argument to code in a language you personally like. Which is exactly what they’re doing. I’m curious - why does all this seem to bother you so much?
    - moloch-hai 4y ago
      "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.
      - Arathorn 4y ago
        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-content-for-the-metaverse/ https://thenewstack.io/third-room-teases-user-generated-cont... has more details.
        moloch-hai 4y ago
        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.
josephg 4y ago
> 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?
- moloch-hai 4y ago
  They could code something useful to other people, instead.

AndyKelley 4y ago

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.

moloch-hai 4y ago
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.
- josephg 4y ago
  If that’s true, it sounds like a strong argument to code in a language you personally like. Which is exactly what they’re doing. I’m curious - why does all this seem to bother you so much?
  - moloch-hai 4y ago
    "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.
    - Arathorn 4y ago
      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-content-for-the-metaverse/ https://thenewstack.io/third-room-teases-user-generated-cont... has more details.
      - moloch-hai 4y ago
        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.

josephg 4y ago

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

moloch-hai 4y ago
They could code something useful to other people, instead.