I fear (and speculate heavily) it is about proofing a point. I’m not sure that this should guide any decision.
4 Likes
It’s not quite that bad: current repo stats according to tokei are 711K Zig to 929K Rust (574K to 732K if discounting comments and blanks). Some of that overhead is likely due to keeping the Zig idioms instead of applying the Rust ones. That’s a good strategy for a first pass, even if the rewrite was done by a human.
I’m not saying that rewrite is entirely sane, but I wouldn’t worry about the line count.
1 Like
They have claimed that compile times are not regressing with this. I guess we’ll see some data on it in the eventual blog post.
3 Likes
Bun Io is based on single-thread Reactor model.
In Zig, bun used vendored usockets (C lib).
In Rust at least in this stage it still uses usockets as far as i understand.
But Rust support single-thread Reactor model natively on both low and high level, so in the future bun’s io will be rust based
You can not implement the same model using new zig’s Io
1 Like
Good to know I’m curious to see the data point, because at work, our backend was rewritten in Rust, and while I really really like it compared to the python implementation, (because the compiler is stricter, hacking something in there without breaking everything is much simpler) the compile time is huge, and the --watch experience is really disappointing coming from Zig. Where in rust even the simplest change can take 10s to rebuild, and mind you the backend is probably 20/30k loc so it’s not huge by any means.
2 Likes
Yeah, this is recent. Podcasting sort of “ran its course” for the founder, but this year we decided to start producing more long-form videos on topics of interest to the community. I’ll keep pitching Zig-related videos until one of them makes the cut!
3 Likes
I also find it a little bit hard to believe. Maybe they were able to keep compile times reasonable by splitting the project among a bunch of crates.
1 Like
First post, yay 
Someone grepped unsafe in the rewrite and it showed up ~15,000 times.
Until they work it all over and deliver it in real Rust, this looks like a PR stunt from Anthropic to me.
5 Likes
Could be.
Jarred has claimed publicly that nobody is forcing him to do anything, but it’s also true that he is an Anthropic employee (albeit one with golden cuffs).
We like to focus on the technical arguments a lot, but it’s a bad idea to forget that there’s a multi-billion dollar company behind it all that just so happens to stand to benefit from a successful port (for varying definitions of ‘successful’).
Maybe the rewrite would have been done better by GPT 5.5, but we shouldn’t expect Jarred to be able to tell us if that was the case, for example.
17 Likes
I downloaded it right now from the github rep and ‘grep -R unsafe * | wc -l’ in the src folder. The result is 14727.
3 Likes
bun still uses C libs at least for Io
but rust supports natively io model required by bun
we don’t need to warry regarding bun+rust
My opinion might be somewhat annoying, but I think Rust written entirely with unsafe could actually be a better language. It doesn’t have all the frustrating restrictions when writing data structures, and compilation is astonishingly fast once you turn off the borrow checker. At the same time, it retains the various advanced features that we need.
2 Likes
The borrow checker is not turned off in an unsafe block. You’d have to use raw pointers for all access, which is incredibly painful syntax-wise.
3 Likes
The borrow checker is not the slow part of the Rust compiler. You can check this yourself: cargo check runs the borrow checker and other checks but does not emit object code etc.
4 Likes
I’m very sorry, I think you are right, Rust’s excellent compilation speed might be attributed to the ability to configure a higher-performance linker, rather than being written using unsafe.
1 Like
In the UK news now:
1 Like
In that article:
Asked whether the Rust version would be maintained mainly by Anthropic’s Claude Code, Sumner said “this is already the status quo; we haven’t been typing code ourselves for many months now. Even pre-acquisition [by Anthropic] this was pretty much accurate.”
So basically they have been vibe coding and they just want better support, aka rust.
5 Likes
Indeed, it does not suggest they actually had too many issues with agentic generation of Zig then
1 Like
Well, std.debug.assert is also effectively turned off in ReleaseFast (because with unreachable the compiler treats these paths are actually not reachable in that mode).
But their assert and assertf is effectively just turning it from a safety-checked undefined behaviour into a panic which you can turn off via a build option (as one can see in that implementation, assertionFailure at some point reaches a call to std.debug.panic).
That’s the point, so that the compiler can optimize it. If you remove the unreachable and replace with a panic, all those assertions still happen in the final release, bringing performance down, and it shows you’re not very confident your program doesn’t have undefined behavior.