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.
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.
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.
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:
And a talk "Zig 2023 Roadmap" that is basically all about compilation speed:
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.