Zig is working on incremental linking, and even hot-code-swapping while your program is running. I would suggest Zig cares more about compilation speed than most other languages, just hasn't gotten there yet.

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.

Zig is plenty fast for a compiled language with optimizations. The Go compiler has no debug/release profiles and the generated machine code isn’t as optimized as say a language using llvm. If you compare it to C++ or Rust, Zig actually has better compile times, and it keeps improving.

Only C++ without incremental compilation, incremental linking and modules.

VC++ does import std in a fraction of time it takes to #include <iostream>.

Many people are not aware that - currently - Zig completely rebuilds your entire application with every compilation - including any parts of the standard library you use. There is not yet any incremental compilation.

It takes a lot of time investment to make compilation fast, and we have gone all in on this investment. There was almost an entire year when not much happened besides the compiler rewrite (which is now done). Finally, we are starting to see some fruits of our labor. Some upcoming milestones that will affect compilation speed:

* x86 backend (90% complete) - eliminates the biggest compilation speed bottleneck, which is LLVM.

* our own self-hosted ELF linker - instead of relying on LLD, we tightly couple our linker directly with the compiler in order to speed up compilation.

* incremental compilation (in place binary patching) - after this Zig will only compile functions affected by changes since the last build.

* Interned types & values. Speed up Semantic Analysis which is the remaining bottleneck of the compiler

* Introduce a separate thread for linking / machine code generation, instead of ping-ponging between Semantic Analysis & linking/mcg

* Multi-threaded semantic analysis. Attack the last remaining bottleneck of the compiler with brute force

Anyway, I won't argue with cold hard performance facts if you have some to share, but I won't stand accused of failing to prioritize compilation speed.

Thanks Andrew, for me a big frustration with Rust is the compilation times coming from Go.

Based on your Milan presentation as well, I have a lot of hope that Zig is seriously pushing on this.