I'm curious how much dollar in LLMs this rewrite cost
Rewrite Bun in Rust has been merged
81–90 of 822 posts
Re: Rewrite Bun in Rust has been merged
#82$ grep --exclude-dir=.git -r 'unsafe {' | wc -l 10465 Nice.
The benefit of using Rust is that you know exactly where the unsafe code is so you can handle it explicitly and deliberately to avoid issues by imposing carefully crafted constraints... oh.
Re: Rewrite Bun in Rust has been merged
#83If this goes wrong even in the slightest , the ridicule about a drug dealer getting high on their own supply will be neverending and grim.
not enough people are emotionally prepared for if it’s not going wrong even in the slightest
Having seen some of the diffs, it's already going wrong in my view.
Re: Rewrite Bun in Rust has been merged
#84$ grep --exclude-dir=.git -r 'unsafe {' | wc -l 10465 Nice.
It's not that weird to end up with this when translating C/Zig/C++ to Rust. A first pass can use unsafe and then when the code is in Rust you can work on reducing the unsafe.
Trying to eliminate all unsafe as part of the rewrite, whether done by human or LLM, would be making too big of a change in the process of rewriting.
Re: Rewrite Bun in Rust has been merged
#85This will go down in history as the biggest mistake of software engineering of all time. Bun is the runtime of Claude Code, which is the core product of a trillion dollar company, which now sits on a vibe-coded app, where not a single person in the world has a proper mental model of.
I don't know, there's been some pretty bad software mistakes, possibly bigger than a PR to convert an app to Rust: https://en.wikipedia.org/wiki/Therac-25
I hope no one ever builds (or even worse, vibe codes) a radiation treatment machine.
Re: Rewrite Bun in Rust has been merged
#86I'm actually excited for somebody trying experimenting with automated translation, but I'm afraid this will be lots of backwards compatibility issues. I started looking at the commits, and it's basically solving the ,,tests not pass'' problem by changing the tests themselves. The real work of making it working on programs that are already deployed will be just starting now. The only silver lining I see is that the se…
> solving the ,,tests not pass'' problem by changing the tests themselves https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed... This is great! Just add a random sleep(1) to a test, don't worry about it, it's going to be fine!
On the other hand, the sleep fits better to the test description, "should allow reading stdout after a few milliseconds". Even if 1 != 'a few'. It's possible the part of the commit reverted here, https://github.com/oven-sh/bun/commit/a42bf70139980c4d13cc55..., defeated the purpose of the test by removing the sleep. I don't think adding the sleep back is an example of AI cheating.
Strange test though either way.
Re: Rewrite Bun in Rust has been merged
#87Re: Rewrite Bun in Rust has been merged
#88Has he estimated the token cost for this (if he had to pay that is)? I'm curious how much this would cost a paying customer.
Re: Rewrite Bun in Rust has been merged
#89Wondering what they will do when rust rejects a pr from them.
Re: Rewrite Bun in Rust has been merged
#90$ grep --exclude-dir=.git -r 'unsafe {' | wc -l 10465 Nice.
It's not that weird to end up with this when translating C/Zig/C++ to Rust. A first pass can use unsafe and then when the code is in Rust you can work on reducing the unsafe. Trying to eliminate all unsafe as part of the rewrite, whether done by human or LLM, would be making too big of a change in the process of rewriting.
> would be making too big of a change in the process of rewriting
God forbid the already unreviewable -710kloc/+1mloc change get any bigger!