Nice idea! I was only thinking about "how could I make Zig more efficient", I didn't even consider making Rust more similar to Zig.

I added a Python script wrapping rustc which serializes all rustc invocations for bun_* crates; you can find the recoridng at [1]. Turns out it only increased the build by 1 minute! So clearly my intuitition that it was just crate parallelism was not correct.

One more confounding factor though is that rustc is parallelised while Zig's compiler is not (yet). So it's still possible that might be the reason.

[1] https://buildprof.lalitm.com/#!/?url=https%3A%2F%2Fblogexamp...

this! - the reason Zig defaults to one semantic analysis thread is due to current (to be improved) limitations; some ideas for Zig also will require one compilation unit - the restricted function pointers proposal being a good example: https://github.com/ziglang/zig/issues/23367

The bun team tried to parallelize Zig's semantic analysis a while back - and it DID compile about 4x as fast... YET the builds were no longer deterministic, which is a hard requirement for lots of things. More effort will need to be spent here than naively adding a thread pool. Hopefully Zig's Sema.zig gets faster, but Rust is also super slow at compiling and needs to improve. Oh - one last thing to note, Zig has very fast debug compilation and incremental compilation, it's a real nice thing to work with that you simply can't approach in most other languages right now.