Comment by toshinoriyagi

>Why would it make sense to use a language that is not helping you manage memory and is slow to compile, especially if you submit a patch to the language to address the issue and get rebuffed?

You're right, other things constant, this would not make sense. But this is a strawman. Zig has fast compilation on average compared to systems languages with more automatic memory management, like Rust. In addition, Bun's fork is based on 0.14 Zig, while 0.16 has become much faster.

Take a look at this post by one of Zig's core maintainers explaining why Zig doesn't want to upstream any changes from the Bun fork: https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio....

In short, the Bun fork introduces non-deterministic compilation errors, a terrible problem for a language and its compiler to have. Zig just made changes to type resolution in 0.16 specifically to allow them to implement parallel semantic analysis, but properly without the bug the Bun fork has.

In addition, they have chosen to spend their time building the self-hosted backend and perfecting incremental compilation, which will have orders of magnitude more benefits to compile times than. Matthew already demonstrates a 4x speedup, what Bun claims to achieve, using the self-hosted backend, and 300x speedups with incremental compilation on a large project (Zig itself).

I am sure it is frustrating for Jarred to not get his patch in, but he was rebuffed for good reason. Bun's fork may have worked for them but many people, including the Zig team, would rather Zig do things properly than introduce bugs and tech debt to make flashy headlines.