The Zig compiler is significantly limited in performance by the llvm backend. Even with a different backend, I also suspect that the language is already complex enough that it is difficult to write a genuinely fast compiler (by which I mean a compiler that can produce good machine code from most files less than say 10k lines of code in under 50ms, which I am quite certain is possible -- but llvm takes about 50ms just to start up and is also slow once it actually starts doing work.)

To write a fast compiler, it has to be fast from the start. It is extremely difficult to make a slow compiler fast because usually there are pervasive design issues that cannot be eliminated by hotspot optimization. These design decisions often reflect the design of the language itself, which is to say that some languages are more amenable to fast compilation than others and I suspect that Zig is at best average or slightly above average for languages of similar expressivity.

I thought Zig was self hosting their compiler now. Am I wrong about that?

You're correct, Zig is self-hosted, with its own non-LLVM backends heavily in development; lots of wildly incorrect statements about both Zig and Go in this thread.

Yes, and when it was announced, it took 2 minutes and IIRC 2-4GB of ram to compile (I believe this was with the LLVM backend). I consider 2 minutes to self compile a language slow. I have personally written a compiler for a simpler language than zig using only lua to bootstrap it and it takes less than a second self compile and 10s of MB of memory. But again, this is possible because this language is much simpler yet in some, but not all, ways it is significantly more expressive than zig.

WRT to the other backends, I was aware of them which is why I said _even with a different backend_. I don't think they have a prayer of self compiling zig in under a second with the current language design with any backend but I'd be happy to be proved wrong.

You're correct: https://kristoff.it/blog/zig-self-hosted-now-what/

I don't think Zig is prevented by its semantics from compiling as fast as Jai or whatever.

> To write a fast compiler, it has to be fast from the start.

The focus on compilation speed is one of the reasons I'm so interested in Zig.

The compiler uses an interesting data-oriented design to represent the AST nodes, etc. You can read about it here:

- https://mitchellh.com/zig/parser#anatomy-of-an-ast-node

- https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-i...

The creator of Zig also has a talk from Handmade Seattle talking about some of the performance gains they've had using these techniques:

- https://vimeo.com/649009599

And a talk "Zig 2023 Roadmap" that is basically all about compilation speed:

- https://www.youtube.com/watch?v=AqDdWEiSwMM

> These design decisions often reflect the design of the language itself, which is to say that some languages are more amenable to fast compilation than others and I suspect that Zig is at best average or slightly above average for languages of similar expressivity.

Extremely correct. In particular, if care isn't taken at the initial design phase of a language to ensure compilation isn't slow, it's likely going to end up being just that. Much in the same way untested code is likely to be incorrect.

Note that I used "isn't slow" instead of "is fast" deliberately. You don't need to, nor should, stress about low-level optimizations, you just need to get the high-level design right. A poorly written quicksort will run circles around the most optimized bubble sort.