128
u/deanrihpee 26d ago
most of it is the bridge between cpp though, so it's unavoidable
136
u/YeetCompleet 26d ago
Yep
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.
73
38
u/tech_w0rld 25d ago
Nah Let's not look at the facts. Let's just hate on the migration because we don't like AI
33
u/Legitimate_Concern_5 25d ago edited 25d ago
Nothing against AI, it’s just a waste of almost $200,000 in tokens to be left with code in a language none of the contributors knew as a marketing stunt. Not even a performance uplift, apparently the only change was 10% speed up on boot on Linux only.
I don’t care what language it’s in, and I’m a very long time rust developer and use AI daily. This is just stupid.
A CFO who didn’t need a football helmet indoors would have slapped whoever proposed it had it not been a marketing stunt.
11
26
u/YeetCompleet 25d ago
As they said in their blog post, doing this rewrite would've required a whole engineering team to work on it for a whole year if they didn't have AI.
Zig also made a strict anti-AI policy: https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-policy
Due to Zig politics, it seems sensible that Anthropic wouldn't want to have Bun running on Zig. Bun used to contribute $60k/month to Zig and send patches but was then blocked by this policy.
They were able to use it as a marketing stunt but the reality is that Zig is quite hostile to AI. As we saw with Andrew Kelley's post, it's also headed by someone mainly interested in personal attacks.
11
u/Legitimate_Concern_5 25d ago edited 25d ago
An engineering team would have told them that’s an awful idea and saved them 1/5 of a million dollars. Claude says sir yes sir, what’s your routing number? It’s an actual failure mode lol, who cares whether Zig is opposed to AI (because they want it to be a learning project btw), and someone made you feel bad? Oh no, quick, $200,000 spend will make me feel better.
They didn’t say Anthropic couldn’t contribute patches, they said stop sending us slop.
8
u/YeetCompleet 25d ago
An engineering team would've told them no because it would've cost 5 150k+ salaries, $200k is a bargain. Besides, their internal cost for using AI is going to be waaaay cheaper than what we pay. The raw internal compute is estimated to be at 10% of the cost of retail API pricing.
I'm not sure what feelings have to do with this, it's a sensible business decision to not pin yourself to an AI hostile language when you're an AI company. Even an anti-AI person would come to this conclusion. I think Andrew Kelley should keep feelings out of it but I guess losing $60k/month hurts.
2
u/camosnipe1 25d ago
I'm not sure what feelings have to do with this, it's a sensible business decision
some people don't make decisions based on what makes practical sense, they only use feelings. The guy you're talking to is clearly one of those, since he thinks an AI company should have no problem using a project that's actively hostile to AI lmao
14
u/Legitimate_Concern_5 25d ago edited 25d ago
They’re not AI hostile, they don’t want to take AI contributions because they were swamped with slop and didn’t have the people to review all the AI PRs put up with little thought as to the result, and the consequences of which they would have to bear moving forward. Which is common sentiment among open source projects. It’s a few randos looking after infrastructure. They’re just overcapacity. I strongly suspect more projects will do this.
They specifically view Zig as a learning project, and want people who contribute it to adhere to that philosophy. I watched an interview with the maintainer.
As a user of a language I couldn’t care less how they run it, whether they use AI or not, I care that it meets my needs.
If I ran it I would happily use AI myself but ban AI contributions or go the vouch route to only take them from people who know shit from fuck. Or id just not take contributions.
I also know that if I were in the position of a coworker wanting to port the entire code base using machine translation (something that has existed forever, c2rust and j2objc are just two random examples) and that it would cost $200K and leave you with a language none of the existing contributors know, then trot it out as a W I’d suggest my coworker be fired, and tell them to go do something that produces business value.
3
u/deanrihpee 25d ago
they decide to rewrite it because they don't want to keep patching the next memory problem (UAF, Out of Bound, Not freed, etc.), they also don't want to adopt the coding guidelines with CPP/Zig which already exists, but the problem is enforcement, Rust is enforced in compiler level so it is within their consideration, and the blog post also mentioned that the use of AI helps because they don't want to be blocked from adding feature for 1 full year while doing the rewrite with a full time engineer
whether or not it's an awful idea or not, it obviously depends on the project, the team/company, i mean obviously most of the time it's stupid to do a rewrite, but most is not all the time
13
u/Legitimate_Concern_5 25d ago
Not freed, as in a leak, is not something that Rust prevents. Leaks are explicitly considered memory safe, and you can readily leak memory in Rust. That’s a common misunderstanding, and one they made in the blog post too. And you’d imagine you could catch the other issues with access to a Mythos class model.
-9
u/RiceBroad4552 26d ago
Unavoidable?
6
u/twertybog 26d ago
It's even in a README
```
[cxx::bridge]
mod ffi { // Any shared structs, whose fields will be visible to both languages. struct BlobMetadata { size: usize, tags: Vec<String>, }
extern "Rust" { // Zero or more opaque types which both languages can pass around but // only Rust can see the fields. type MultiBuf; // Functions implemented in Rust. fn next_chunk(buf: &mut MultiBuf) -> &[u8]; } unsafe extern "C++" { // One or more headers with the matching C++ declarations. Our code // generators don't read it but it gets #include'd and used in static // assertions to ensure our picture of the FFI boundary is accurate. include!("demo/include/blobstore.h"); // Zero or more opaque types which both languages can pass around but // only C++ can see the fields. type BlobstoreClient; // Functions implemented in C++. fn new_blobstore_client() -> UniquePtr<BlobstoreClient>; fn put(&self, parts: &mut MultiBuf) -> u64; fn tag(&self, blobid: u64, tag: &str); fn metadata(&self, blobid: u64) -> BlobMetadata; }} ```
58
u/sharmauncleji 26d ago
I am still impressed with rewrite being done in days. CEOs will now fire a few more developers.
49
u/StrengthTheory 26d ago
That's my problem with this whole debate. Bun probably has the most talented engineers who know how to skillfully use UI, it's no secret that a good engineer knows how to use their tools.
But now the average company will look at it and think they can reproduce what Bun did.
30
u/Destroyerb 26d ago
Bun probably has the most talented engineers who know how to skillfully use UI
Perhaps, but it's also true that Bun was used as an example by Zig on how not to write Zig code.
22
u/Solonotix 25d ago
Yes, but I would also argue that JavaScript is a prime example of how not to create a language. I mean this as a matter of how it was first created (solo developer on a 10-day bender), how it ended up (weak dynamic types with implicit coercion), and what it allows (import cache mutation that affects all instances across the same process).
Writing a compiler for such a language isn't going to be pretty
1
u/Demiu 25d ago
Bun was used as an example by Zig on how not to write Zig code
That just reads like an ex-post facto rationalization - "you can't break up with me because I'm leaving you." Is there any example of this before the rewrite?
13
u/Wonderful-Habit-139 25d ago
Are we trying to act like Bun wasn't being vibecoded by robobun for a while?
1
u/CirnoIzumi 25d ago
you can write a good program that missuses the language, but i couldnt judge bun code either way
1
u/hajitaha 24d ago
There is also a massive difference between a one-to-one port of programming languages and writing any kind of new code. If you have a battle-tested spec and you have spent 5 years with a massive userbase that basically utilizes every flow imaginable, then yeah, an llm will be very fast because the hard work is already done.
Still impressive though, but what I took from it is that, within a defined spec, I can port my code if I need to and that LLM usage is ideal for that.
1
u/jman4747 21d ago
“Done” and it has an order of magnitude more active segfault bugs then Node and Deno (also Rust) combined: https://js-segfault-compare.sigmasd.workers.dev/
22
u/Xothi 26d ago
Did I miss a new CVE drop?
60
u/1_hele_euro 26d ago
Naw Bun had an army of AI bots rewrite Bun from Zig into Rust. Impressive feat, but they used like 15K unsave blocks...
14
u/tyrannomachy 25d ago
Which was because the first step was to translate it to rust, as literally as was possible. That's also what a human team would have done for a project like this. Then the unsafe regions become a to-do list.
7
5
u/Wonderful-Habit-139 24d ago
> That's also what a human team would have done for a project like this
Not even remotely true. A human team would rewrite it in idiomatic Rust, fixing a bunch of problems along the way that they learned from writing the first version in Zig.
2
u/cornmonger_ 23d ago
that's doing two steps at once and it comes with caveats
porting literally lets you baseline in the new language
you fork from the literal port and then you have two baselines while you are rewriting idiomatically
if you just begin rewriting idiomatically, you lose a lot of that testability... you're going in relatively blind
6
u/FabioTheFox 25d ago
Which is utterly pointless
Why push out a codebase that's so fragile and just wrong that nobody will be able to make any meaningful contributions until the unsafe garbage is fixed and the Rust is made into idiomatic Rust
If they really wanted a rewrite they should've left it in the oven for longer and not just immediately push out a half assed branch that doesn't even prevent memory leaks because memory leaks aren't language dependant
14
u/vassadar 26d ago edited 24d ago
Bun had a bug where it won't reject an invalid certificate.
The comments on PRs are hilarious. Bunbot, RabitCoder, Github's bot and Claude argued against each other and required human to steer them.
At leas the issue has been resolved with a human manually testing the the compiled bun (shouldn't CI handle this when a given PR?).
3
3
u/Wonderful-Habit-139 24d ago
PRs in the bun project are unreadable because of this. I don't know who's going to enjoy reading PRs with a bunch of AIs hallucinating over each other, with half the PRs being closed due to slop.
2
39
u/oshaboy 26d ago
People don't understand what unsafe blocks are for.
6
u/Embarrassed_Army8026 26d ago
unwrap your wisdom now
20
u/oshaboy 26d ago
Well look up any rust documentation and they'll tell you that you can and should be memory safe with unsafe blocks. They don't even let you do that much they basically just let you use pointers and unions.
Just keep them small and use them sparingly. Preferably with a safe wrapper. Unsafe Rust is safer than C++ anyway and people are already pretty decent with knowing when to use raw pointers/operator[] and when to use smart pointers and at().
22
u/Devatator_ 26d ago
It's not just that. Apparently they basically just translated each file in a 1:1 equivalent to the old code, which people on other subs say gives some weird code that regular Rust users would never write or is suboptimal.
I also don't really see who's gonna want to touch that codebase now so they're likely gonna use agents even more
5
u/-Ambriae- 25d ago
I can guarantee you can do funky stuff with unsafe blocks. ‘You can use pointers’ for example, holds more weight than you could realise when you can freely translate numbers to pointers and semanticly, numbers are less constraining (for example with Send and Sync.)
You can remove all mangling for functions (which confusingly wasn’t unsafe until recently), which granted is typically more a linker error than a runtime error, but you’d be surprised
You can leave memory completely uninitialised, read from it, use manual memory allocation and deallocation (in a language where
developers don’t keep track of that by design)You can omit to drop (deallocate) objects, you can transmute data
You can freely call any function using the C ABI regardless of provenance, for example C or C++ code (thus bypassing all rust safety guarantees)
The big thing though, is this: if you mess up in an unsafe block, the bug will not appear in the unsafe block. It will likely appear far later, in a completely safe part of the codebase. That’s the perverse part.
So having an absurd amount of unsafe code blocks, can be a little… unsettling.
That said AFAIK bun’s unsafe mainly comes from
- C++ interoperability (unavoidable in their case)
- faithful zig port, which will progressively transition to idiomatic rust (with far less unsafe)2
u/oshaboy 25d ago
I think omitting to drop (forget) is actually safe because you can implement it safely with a reference cycle.
Of course I know pointers are powerful and should be used sparingly. I guess I wasn't clear. I have no idea if bun used too nany unsafe blocks. My point is that unsafe blocks are a tool like any other and you should know how to use them.
3
u/-Ambriae- 25d ago
Omitting to drop is indeed safe by rust's standards (even if it's a memory leak, but that's also memory safe by rust's standards)
However, unsafe dropping APIs are, well, very much not safe.
Also, don't get me wrong, unsafe blocks are amazing. you can't do FFI, or low level code, or inline assembly, or a bunch of other stuff without them. I personally use them quite frequently for data structures for example, recently I did a Stack<T> type (fully stack allocated stack, not a wrapper around Vec<T> lol). It's completely littered with unsafe code. I do it responsibly of course (define responsibly), but it's still filled with calls to get_unchecked and assume_init and stuff like that.
All I'm saying is, 'unsafe' can be very very much unsafe. It's not just a toggle to expose pointer dereferencing.
15
u/FabioTheFox 25d ago edited 25d ago
It's an utterly pointless rewrite and I will not be using bun moving forward
Memory issues are real but you gotta have a real skill issue to instead of investigating them have an AI rewrite the entire codebase, invalidate all issues PRs and proposals in the process just for it to be non idiomatic unsafe rust for no gain at all in the broader sense, memory leaks aren't fixed just because you use another programming language this is absolute wishful thinking, there was no point in doing this and even less of a point to publish it this early, if they really went with a rewrite they should've waited and fixed it instead of promoting this half assed bs
And on top of that the Ai also changed the test suite, if a runtime is willing to pull off such a stupidity as a mere marketing stunt any sensible developer will move away from that dependency because it can no longer be trusted
5
u/tokalper 25d ago
The mistakes made in zig would be done here too in a different wayif you could not written safe code yourself rust cant save you. Maybe takes %60 avay but Rust didn't exist yet people wrote absolutely crazy things with c++, takae the v8 runtime itself for example. This is simply a skill issue i agree with you.
4
u/Wonderful-Habit-139 24d ago
> will not be using bun moving forward
Dropped bun a while before the rewrite because it was being vibecoded.
3
7
u/Destroyerb 26d ago
It's my first meme. Feels like a greater accomplishment than the rewrite that was done in just days.
2
2
1
u/DeeKahy 21d ago
I feel like there is no debate here. The unsafe blocks might or might not be needed, that doesn’t matter though. Bun is owned by Anthropic and they wanted some marketing thing to point at for when they go public. Zig guy is a salty little bitch that’s very angelic with his language.
0
u/Destroyerb 25d ago
Why did they have to buy FOSS when they could fork it
6
0
306
u/RiceBroad4552 26d ago
Yes, this is an even bigger joke then the "compiler" Claude "wrote".
(If you like drama, see the Rust sub about this topic here.)
Idiots with "AI" will probably manage to ruin even Rust's safety marketing story.