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

Bun has been converted to rust. Now what?

bytecode.news

Post reply on HN
Print view View original

11–20 of 113 posts

Re: Bun has been converted to rust. Now what?

#11

Post by rcxdude »

jottinger wrote: post #2

Bun was ported from Zig to Rust by an LLM and passed nearly all its tests - while shipping more than ten thousand unsafe blocks. Memory safety is the main reason you'd pick Rust. So what did the rewrite actually accomplish?

It's generally best to do the port as directly as possible, even if the resulting code is ugly in the target language, then refactor to fit the new language better. Doing both at once can make things a lot more difficult. (With porting you generally want to have as little time as possible where everything is 'in pieces' and the port is non-functional, hence why gradual processes are usually required for larger projects)

Re: Bun has been converted to rust. Now what?

#14

Post by simonw »

> There is a small, ironic coda. The follow-up PR to delete the 600,000 or so lines of leftover Zig was titled, by Sumner, "ai slop." GitHub's automated anti-slop detection - built to flag exactly the kind of AI-generated mass change this was - caught it and auto-closed it. The author named his own cleanup slop, and the platform's tooling agreed.

That looked suspicious to me (you could almost say hallucinated...), so I checked it out. Here's the GitHub Action that adds that comment - written by Jarred back in February, so it's not accurate to classify it as "GitHub's automated anti-slop detection". https://github.com/oven-sh/bun/commit/c01a5e08be896e1d1f4529...

It was Jarred who deliberately added the slop label to that PR, which triggered the Action comment: https://github.com/oven-sh/bun/pull/30680#event-25523046939

Re: Bun has been converted to rust. Now what?

#15

Post by dralley »

jottinger wrote: post #2

Bun was ported from Zig to Rust by an LLM and passed nearly all its tests - while shipping more than ten thousand unsafe blocks. Memory safety is the main reason you'd pick Rust. So what did the rewrite actually accomplish?

Considering a substantial fraction of the commit history since then has been removing those instances of "unsafe" not all of are actually usages of "unsafe" (seems like there are a fair number of functions / types with unsafe in the name but not the signature), is that actually still true?

And if nothing else Rust forces you to document where they are, which isn't nothing.

Re: Bun has been converted to rust. Now what?

#16

Post by mpalmer »

rcxdude wrote: post #11
jottinger wrote: post #2

Bun was ported from Zig to Rust by an LLM and passed nearly all its tests - while shipping more than ten thousand unsafe blocks. Memory safety is the main reason you'd pick Rust. So what did the rewrite actually accomplish?

It's generally best to do the port as directly as possible, even if the resulting code is ugly in the target language, then refactor to fit the new language better. Doing both at once can make things a lot more difficult. (With porting you generally want to have as little time as possible where everything is 'in pieces' and the port is non-functional, hence why gradual processes are usually required for larger projec…

It's generally best to do several things that no one did here.

Re: Bun has been converted to rust. Now what?

#19

Post by embedding-shape »

> The Rust rewrite passed 99.8% of the existing test suite. That number is enormous and significant, but let's be precise about what it actually says

I'm having a hard time even loading the PR, so can't look myself... But I seem to remember that there was changes to the test suite as well as the rewrite to the Rust engine, that would mean this number may or may not actually be accurate. Anyone remember or could actually load the PR and see? That'd make this article weirdly under-researched and missing something kind of vital.

Re: Bun has been converted to rust. Now what?

#20

Post by embedding-shape »

elnatro wrote: post #3

Deno was already implemented in Rust, and not done by vibe-coding. Would you trust a fully vibe-coded runtime? Not some features, not some fixes, but a full translation from one language to another.

Current feedback says: "yes", "hell no" and "no" so I guess I'll add this so we come full circle:

It depends.

Post reply on HN