Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewrite Bun in Rust has been merged

github.com

Post reply on HN
Print view View original

91–100 of 822 posts

Re: Rewrite Bun in Rust has been merged

#91

Post by robryan »

q3k wrote: post #56
xiphias2 wrote: post #6

I'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!

To be fair the commit message `revert proc.exited change in spawn.test.ts` suggests the sleep was there originally.

Re: Rewrite Bun in Rust has been merged

#92

Post by K0nserv »

q3k wrote: post #90
K0nserv wrote: post #84

Earlier quoted context omitted.

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!

Sure, but that's kind of orthogonal. Imagine doing this by hand I still think going like-for-like with the Zig, even if that means a lot of unsafe, is a good approach.

But I suppose if you are already using LLMs it's more reasonable to try and go from Zig straight to Rust with no/minimal unsafe.

Re: Rewrite Bun in Rust has been merged

#93

Post by janice1999 »

Jarred wrote: post #76

Still writing the blog post about this. Will share more details. For where this is coming from, skim the bugfixes in the Bun v1.3.14 and earlier release notes. Rust won’t catch all of these - leaks from holding references too long and anything that re-enters across the JS boundary are still on us. But a large % of that list is use-after-free, double-free, and forgot-to-free-on-error-path, which become compile errors…

I'm curious how much this would cost a paying customer. Can you please give us an estimate?

Re: Rewrite Bun in Rust has been merged

#94

Post by robryan »

applfanboysbgon wrote: post #65
NitpickLawyer wrote: post #57

Earlier quoted context omitted.

> Claude Code itself is purely vibecoded [...] money they intend to squander [...] going to burn themselves to the ground getting high on their own supply. This really really really isn't the burn you think it is. Going from 0 to 2B+ in revenue from a "purely vibecoded" thing is what they've said they're doing, and what they've actually done. Like in already done. It's not going back, no matter how many nuh nuh peopl…

2B+ in revenue on hundreds of billions in investments and future commitments is completely worthless. Anybody can turn $100b into $2b, that's not a fucking accomplishment. And to the extent that something is driving any revenue, it is the model, not the TUI. Any success Claude is having is despite the godawful TUI, not because of it.

They appear to be lining up a funding round at a $900 billion dollar valuation. Or to be more conservative they already raised at $380 billion. A long way from worthless.

Re: Rewrite Bun in Rust has been merged

#95

Post by embedding-shape »

eddiewithzato wrote: post #77
Jarred wrote: post #76

Still writing the blog post about this. Will share more details. For where this is coming from, skim the bugfixes in the Bun v1.3.14 and earlier release notes. Rust won’t catch all of these - leaks from holding references too long and anything that re-enters across the JS boundary are still on us. But a large % of that list is use-after-free, double-free, and forgot-to-free-on-error-path, which become compile errors…

I can hope this will lead to little to no memory issues in using bun as a web server

I'd be surprised if they could eliminate memory issues completely, especially considering the amount of `unsafe` the codebase seems to contain.

    git rev-parse HEAD && ag "unsafe" src | wc -l
    19d8ade2c6c1f0eeae50bd9d7f2a4bf4a2551557
    14865

Re: Rewrite Bun in Rust has been merged

#96

Post by adityashankar »

debugnik wrote: post #83
teterphiel wrote: post #75

Earlier quoted context omitted.

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.

Curious can you elaborate on this?

Re: Rewrite Bun in Rust has been merged

#97

Post by chrysoprace »

perching_aix wrote: post #22

PR so thick, the page failed to load the first time I opened it, and the comments still continue to fail to load. Absolutely hilarious. Though that may be just GitHub having a normal one, hard to tell these days. 1 009 257 lines added 4024 lines removed 6755 commits 2188 files touched I haven't the slightest clue how anyone would even remotely hope to review this. I guess by just using even more AI? Or maybe by throw…

Not sure there is much of a point in reviewing a port of this size. It has >1000 instances of `unsafe` and uses the same patterns as the zig code according to Jarred. It feels like a vibe-ported version of what the TypeScript team are doing porting from TypeScript > Go with codemods.

Re: Rewrite Bun in Rust has been merged

#99

Post by Jarred »

xiphias2 wrote: post #6

I'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…

> it's basically solving the ,,tests not pass'' problem by changing the tests themselves.

False.

0 test files were deleted. 0 pre-existing tests were skipped, todo’d, or had assertions removed. 5 new tests were added in test.skip/test.todo state to track known not-yet-fixed bugs in the port that lacked test coverage before.

The merge changed 28 test files in total.

+1,312 lines

−141 lines

Most of that +1,312 is new tests.

The depth-of-recursion tests for TOML/JSONC parsers went from 25_000 -> 200_000 because Rust’s smaller stack frames (LLVM lifetime annotations let the optimizer reuse stack slots) mean 25k levels no longer reaches the 18 MB stack on Windows.

Re: Rewrite Bun in Rust has been merged

#100

Post by janice1999 »

teterphiel wrote: post #75
eqvinox wrote: post #18

If 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

It's going to work for the most part. Most people know that. It's a file by file, mostly function by function, conversion from one low level language to another with a very large test suite (with lots of Rust unsafe to work around differences). I've done that for C tools and it's fine, with some obscure edge cases here and there. The challenges are going to be making the new, very ugly, alien codebase idiomatic Rust in future and adding features or debugging the complex issues. I wish the developers luck. They're in for a slog.
Post reply on HN