7 ms·

To me the most interesting fact about this fork is that it has proven that Bun could have had fast builds all along. To be fair, there are caveats still in pla

To me the most interesting fact about this fork is that it has proven that Bun could have had fast builds all along. To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.

dtj1123 2mo ago
After the all the noise surrounding the forking of the Zig compiler in order to speed up builds, I'm really surprised that this isn't the top comment. The fact that a one-man team achieved 1s build times proves pretty conclusively that slow build times were entirely result of negligent development practices, and that the fork was a complete misallocation of time.
- skeledrew 2mo ago
  A significant part of the port was also for the built-in safety. Unsafe code just... fails to compile. Turns out there's a journey here.
  - Philip-J-Fry 2mo ago
    The port was line for line and full of unsafe code. It didn't prevent any bugs. They're not using Rust for its strengths.
    - neuronexmachina 2mo ago
      That may have been the case for the initial iteration a few months ago, but is it still true?
    - skeledrew 2mo ago
      You should give the article[0] a read. "A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide." "At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects." [0] https://bun.com/blog/bun-in-rust https://bun.com/blog/bun-in-rust
      - bunderbunder 2mo ago
        That one’s interesting to me because it speaks to both sides of the debate. Yes, safe Rust is good for catching those kinds of errors at compile time. But also, it should theoretically be very easy for a compiler to avoid those problems in Zig, too, if you are using the language the way it wants to be used. Which, from what I’ve experienced so far, does seem to take a whole lot more effort if you’re using a coding agent. I spend an incredible amount of time making sure mine doesn’t bloat our codebase with Java-flavored Python, and all the noise and defects and performance problems that it brings.
        skeledrew 2mo ago
        > using the language the way it wants to be used. This sounds like just the coding conventions dependency they're trying to avoid.
        bunderbunder 2mo ago
        Yup. But that also gets to the “they’re both right” angle. Zig’s convention may not be how the Bun developers wanted to work, but it’s a good choice for the kinds of projects Zig is designed for. Which overlaps a bit with, but isn't the same as, Rust’s intended use cases. For example, I might rather go with the Zig philosophy if I’ve got hard memory constraints and want to avoid dynamic memory allocation. Which, ironically, is something I’d love for my browser’s JavaScript runtime to do. But I can also respect others not wanting that.
        TheGoddessInari 2mo ago
        IMO it's the same problem with Rust. LLMs are trained on vast quantities of code that violate Rust soundness in safe code. LLMs are prediction engines: you can move the needle (heavily) on the predictions from lazy to correct by construction, but the defaults even on high end models like Opus are always riddled with shortcuts. LLMs can produce coherent & safe Rust 1.92, LLMs can produce coherent Zig 0.16, but that's dependent on in context learning & instruction following.
    - samwillis 2mo ago
      They have made it very clear that the mechanical translation is the starting point, and are refactoring to remove as many unsafe declarations as possible.
    - insanitybit 2mo ago
      They turned every hidden memory safety bug into a grep'able memory safety bug. That's step 1 and a massive win.
    - atombender 2mo ago
      The original Zig code is metaphorically one big unsafe block. Even if the Rust port is made up of 3% unsafe blocks, that still means 97% of the original Zig code has been made safe (in the Rust sense).
      - audunw 2mo ago
        Since they did a one-to-one translation to start with, hypothetically, if these were the true numbers, you could probably get a static analysis tool to guarantee you that 97% of the zig code was safe and tell you which of the 3% were unsafe. Zig has a lot more syntax and conventions to encourage safe code compare to C after all. It just doesn’t have way to mark which parts are safe or unsafe. An LLM could probably also trivially give you accurate reviews saying which parts were unsafe and in need of tests or reviews. I mean, considering their LLM budgets they could probably have had nightly reviews running every night for years before spending more than their Rust rewrite. Not that I think Rust rewrite was a bad idea. Rust is a good fit for this kind of project. I say that as a Zig enthusiast. It’s just that their stated motivation and reported results are kinda BS. If they just wrote “we just like Rust and thought it’d be cool to see of LLM could do the whole rewrite”, and left it at that, I think it’d be a more honest description of the motivation. The rest is just rationalisation.
        Zakis1 2mo ago
        No you cannot get a static analysis tool to guarantee 97% of zig code was safe. Well, you can - the tool is called the borrow checker. Do you know what's infinitely cheaper and faster than an LLM running nightly reviews of all of the code and infact mathematically provable that the code (and any new code) is memory safe? It's called the borrow checker.
        dnautics 2mo ago
        it seems like a reasonable enterprise to intercept the data dependency graph from the zig compiler and subject it to analysis to prove memory safety parameters: (my wip experiment: ) https://github.com/ityonemo/clr https://github.com/ityonemo/clr
  - GuB-42 2mo ago
    GP is talking about the fork of the Zig compiler, not the rewrite of Bun into Rust. Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from 2 minutes to 30 seconds, but, according to the Zig team, it made compilation non-deterministic, and missed on the real improvement they worked on, which was sub-1s incremental builds. "Buz" shows that the fork submitted by Anthropic wasn't needed as Bun can now compile under 1s (incrementally), which is much better than the 30s they achieved with their patch. It is likely that this rejection, especially the "no AI" aspect of it encouraged Anthropic to move away from Zig.
    - dminik 2mo ago
      Is there anything suggesting that Bun even attempted to submit their Zig patches? As far as I know, they were stuck 2 versions behind. With the amount of changes and Zig already working on incremental I'm not sure what the point would have been.
      - kristoff_it 2mo ago
        Yes it was never attempted, the whole communication on social media about the AI policy was completely detached from the reality of the engineering work being done on either side.
    - dtj1123 2mo ago
      Yep, on rereading my comment I totally failed to make this clear. Cheers.
- IshKebab 2mo ago
  I'm pretty sure they forked Zig long before it supported incremental compilation. In fact, it's still experimental and not enabled by default.
- hoppp 2mo ago
  The port was a political decision. It's now the runtime for claude code first and it must align itself in that ecosystem by becoming fully vibe code.
ozgrakkurt 2mo ago
This is an example of technical problems being easy but organization being hard imo. It is stupid if you think about it from a theoretical perspective but they didn’t want to use this feature for some reason. Probably because they did their fork of zig for fast compilation before and they didn’t want to just discard it and use this
janpio 2mo ago
Do the caveats mean that it could _not_ actually have had fast builds on all the platforms it supports? (Honestly asking if I connected the dots correctly here, this is not a snarky "actually" rethorical question...)

dtj1123 2mo ago

After the all the noise surrounding the forking of the Zig compiler in order to speed up builds, I'm really surprised that this isn't the top comment. The fact that a one-man team achieved 1s build times proves pretty conclusively that slow build times were entirely result of negligent development practices, and that the fork was a complete misallocation of time.

skeledrew 2mo ago
A significant part of the port was also for the built-in safety. Unsafe code just... fails to compile. Turns out there's a journey here.
- Philip-J-Fry 2mo ago
  The port was line for line and full of unsafe code. It didn't prevent any bugs. They're not using Rust for its strengths.
  - neuronexmachina 2mo ago
    That may have been the case for the initial iteration a few months ago, but is it still true?
  - skeledrew 2mo ago
    You should give the article[0] a read. "A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide." "At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects." [0] https://bun.com/blog/bun-in-rust https://bun.com/blog/bun-in-rust
    - bunderbunder 2mo ago
      That one’s interesting to me because it speaks to both sides of the debate. Yes, safe Rust is good for catching those kinds of errors at compile time. But also, it should theoretically be very easy for a compiler to avoid those problems in Zig, too, if you are using the language the way it wants to be used. Which, from what I’ve experienced so far, does seem to take a whole lot more effort if you’re using a coding agent. I spend an incredible amount of time making sure mine doesn’t bloat our codebase with Java-flavored Python, and all the noise and defects and performance problems that it brings.
      - skeledrew 2mo ago
        > using the language the way it wants to be used. This sounds like just the coding conventions dependency they're trying to avoid.
        bunderbunder 2mo ago
        Yup. But that also gets to the “they’re both right” angle. Zig’s convention may not be how the Bun developers wanted to work, but it’s a good choice for the kinds of projects Zig is designed for. Which overlaps a bit with, but isn't the same as, Rust’s intended use cases. For example, I might rather go with the Zig philosophy if I’ve got hard memory constraints and want to avoid dynamic memory allocation. Which, ironically, is something I’d love for my browser’s JavaScript runtime to do. But I can also respect others not wanting that.
        TheGoddessInari 2mo ago
        IMO it's the same problem with Rust. LLMs are trained on vast quantities of code that violate Rust soundness in safe code. LLMs are prediction engines: you can move the needle (heavily) on the predictions from lazy to correct by construction, but the defaults even on high end models like Opus are always riddled with shortcuts. LLMs can produce coherent & safe Rust 1.92, LLMs can produce coherent Zig 0.16, but that's dependent on in context learning & instruction following.
  - samwillis 2mo ago
    They have made it very clear that the mechanical translation is the starting point, and are refactoring to remove as many unsafe declarations as possible.
  - insanitybit 2mo ago
    They turned every hidden memory safety bug into a grep'able memory safety bug. That's step 1 and a massive win.
  - atombender 2mo ago
    The original Zig code is metaphorically one big unsafe block. Even if the Rust port is made up of 3% unsafe blocks, that still means 97% of the original Zig code has been made safe (in the Rust sense).
    - audunw 2mo ago
      Since they did a one-to-one translation to start with, hypothetically, if these were the true numbers, you could probably get a static analysis tool to guarantee you that 97% of the zig code was safe and tell you which of the 3% were unsafe. Zig has a lot more syntax and conventions to encourage safe code compare to C after all. It just doesn’t have way to mark which parts are safe or unsafe. An LLM could probably also trivially give you accurate reviews saying which parts were unsafe and in need of tests or reviews. I mean, considering their LLM budgets they could probably have had nightly reviews running every night for years before spending more than their Rust rewrite. Not that I think Rust rewrite was a bad idea. Rust is a good fit for this kind of project. I say that as a Zig enthusiast. It’s just that their stated motivation and reported results are kinda BS. If they just wrote “we just like Rust and thought it’d be cool to see of LLM could do the whole rewrite”, and left it at that, I think it’d be a more honest description of the motivation. The rest is just rationalisation.
      - Zakis1 2mo ago
        No you cannot get a static analysis tool to guarantee 97% of zig code was safe. Well, you can - the tool is called the borrow checker. Do you know what's infinitely cheaper and faster than an LLM running nightly reviews of all of the code and infact mathematically provable that the code (and any new code) is memory safe? It's called the borrow checker.
        dnautics 2mo ago
        it seems like a reasonable enterprise to intercept the data dependency graph from the zig compiler and subject it to analysis to prove memory safety parameters: (my wip experiment: ) https://github.com/ityonemo/clr https://github.com/ityonemo/clr
- GuB-42 2mo ago
  GP is talking about the fork of the Zig compiler, not the rewrite of Bun into Rust. Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from 2 minutes to 30 seconds, but, according to the Zig team, it made compilation non-deterministic, and missed on the real improvement they worked on, which was sub-1s incremental builds. "Buz" shows that the fork submitted by Anthropic wasn't needed as Bun can now compile under 1s (incrementally), which is much better than the 30s they achieved with their patch. It is likely that this rejection, especially the "no AI" aspect of it encouraged Anthropic to move away from Zig.
  - dminik 2mo ago
    Is there anything suggesting that Bun even attempted to submit their Zig patches? As far as I know, they were stuck 2 versions behind. With the amount of changes and Zig already working on incremental I'm not sure what the point would have been.
    - kristoff_it 2mo ago
      Yes it was never attempted, the whole communication on social media about the AI policy was completely detached from the reality of the engineering work being done on either side.
  - dtj1123 2mo ago
    Yep, on rereading my comment I totally failed to make this clear. Cheers.
IshKebab 2mo ago
I'm pretty sure they forked Zig long before it supported incremental compilation. In fact, it's still experimental and not enabled by default.
hoppp 2mo ago
The port was a political decision. It's now the runtime for claude code first and it must align itself in that ecosystem by becoming fully vibe code.

ozgrakkurt 2mo ago

This is an example of technical problems being easy but organization being hard imo. It is stupid if you think about it from a theoretical perspective but they didn’t want to use this feature for some reason. Probably because they did their fork of zig for fast compilation before and they didn’t want to just discard it and use this

janpio 2mo ago

Do the caveats mean that it could _not_ actually have had fast builds on all the platforms it supports? (Honestly asking if I connected the dots correctly here, this is not a snarky "actually" rethorical question...)