Remix.run Logo
kristoff_it 4 hours ago

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 3 hours ago | parent [-]

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 3 hours ago | parent | next [-]

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 2 hours ago | parent [-]

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.

skeledrew 2 hours ago | parent | next [-]

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

bunderbunder an hour ago | parent [-]

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 an hour ago | parent [-]

> using the language the way it wants to be used.

This sounds like just the coding conventions dependency they're trying to avoid.

atombender an hour ago | parent | prev | next [-]

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 16 minutes ago | parent [-]

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 a few seconds ago | parent [-]

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 rather? It's called the borrow checker.

insanitybit an hour ago | parent | prev | next [-]

They turned every hidden memory safety bug into a grep'able memory safety bug. That's step 1 and a massive win.

samwillis 2 hours ago | parent | prev | next [-]

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.

neuronexmachina 2 hours ago | parent | prev [-]

That may have been the case for the initial iteration a few months ago, but is it still true?

IshKebab 2 hours ago | parent | prev [-]

I'm pretty sure they forked Zig long before it supported incremental compilation. In fact, it's still experimental and not enabled by default.