Live data from Hacker News

Rewrite Bun in Rust has been merged

github.com

661–670 of 822 posts

Re: Rewrite Bun in Rust has been merged

#661

Earlier quoted context omitted.

Model open source leadership. Imagine the meltdown if Linus says Linux kernel is not going to be rewritten and then one day wakes up and merges full machine-assisted rewrite in Rust.

As long as it was still GPL and it wasn't just license washing, I'd be elated.

You won't be when you can't boot your system anymore on x86.

Re: Rewrite Bun in Rust has been merged

#662
post #368

When announcements say that rewrite took 1 week, I wonder how much time went into preparing this file with very detailed instructions on mapping Zig to Rust idioms: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573... On top of that, if you look at 'Pointers & ownership' and 'Collections' sections, the Bun codebase is already prepared, using internal smart pointer types that map 1-to-1 to Rust equivalents,…

Yes, there is exaggeration going on.

Nonetheless, it’s a fact it would have taken much longer without LLMs, I’d say all possible.

I find this is a valid success story if you can look past the embellishments. More than that, it’s really cool, actually.

Re: Rewrite Bun in Rust has been merged

#663
Given Anthropic's existing track record of producing terrible hallucinated inaccurate documentation in Claude Code, I'm very curious how Bun will handle this as it continues development. Anthropic probably doesn't care about Bun's external compatibility as long as it runs Claude Code. Will Bun be eventually become "the JavaScript flavor that Claude Code uses"? Will they even bother updating external documentation as it changes? Docs currently live at https://bun.com/reference, but I don't know how much of this is separately maintained documentation versus JSDoc-style generated documentation.

Re: Rewrite Bun in Rust has been merged

#664
post #539

Earlier quoted context omitted.

I'm really out the loop here so maybe you can help answer me a question - why is HN unhappy about this rewrite? why are people writing here almost as if they feel betrayed by Bun being rewritten from Zig into Rust? I genuinely don't get it. I've been following this Bun stuff a bit but I don't understand where the HN sentiment is coming from.

Vibe coding a Rust rewrite of a widely used tool is basically catnip for the HN crowd.

Not if you use that tool, then it's just scary.

Re: Rewrite Bun in Rust has been merged

#665
post #99
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 t…

That's great!

It's too bad you haven't structured the commits and pull requests a bit differently so that it's easier to review the exact changes, but I hope it goes well.

For example doing the test refactorings in a first pull request, and using something like test.xfail that is first fails then after the merge succeeds (but the test code itself doesn't change).

Also I have seen some tests getting stricter, which is again not a problem, but separating to a different pull request would have improved the reviewability significantly for a runtime that many people and companies depend on.

I'm sorry you were downvoted by HN and your comment got ,,dead'', that's not the way to review things.

Re: Rewrite Bun in Rust has been merged

#666

Earlier quoted context omitted.

Yeah I don’t know what’s true when reading about LLMs. Same with comments here on hacker news. So much money on the line it’s clear they would seed communities with marketing shills (and some people are just tribal). Same since they own Bun, they have every incentive to make this seem easier than it was.

You can just use AI for yourself and see. It isn't some mysterious product that only a few people get to use.

I think we're still seeing pretty wild variance in how effective LLMs can be for code, depending on who is driving it. I've seen some folks getting themselves into messes pretty regularly with LLMs. But, ever since Opus 4.5, it's been pretty obviously better to work with it than without it, remarkably better in some use cases. Porting an application with source available and a huge existing test suite is pretty much the ideal use case for an LLM. It has everything it needs to succeed. I can't imagine why anyone would embark on a porting effort without an LLM at this point.

Re: Rewrite Bun in Rust has been merged

#667

Earlier quoted context omitted.

The analogy is just bad to begin with. It's more like "we've switched ingredients while actively denying that they'll be switched".

They never denied they'd switch, just that they'd need solid improvements confirmed before they switched. Clearly internally they've decided they've seen the gains necessary to carry on with the switch

https://news.ycombinator.com/item?id=48019226

> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely

I know words are hard, but if you find it hard to believe any humans here, then feed it into your favorite LLM.

Re: Rewrite Bun in Rust has been merged

#668

Earlier quoted context omitted.

Yeah I don’t know what’s true when reading about LLMs. Same with comments here on hacker news. So much money on the line it’s clear they would seed communities with marketing shills (and some people are just tribal). Same since they own Bun, they have every incentive to make this seem easier than it was.

You can just use AI for yourself and see. It isn't some mysterious product that only a few people get to use.

While this is true, it's also true that few people have the budget to spend a bunch of tokens on porting bun over to rust.

Re: Rewrite Bun in Rust has been merged

#669
post #368

When announcements say that rewrite took 1 week, I wonder how much time went into preparing this file with very detailed instructions on mapping Zig to Rust idioms: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573... On top of that, if you look at 'Pointers & ownership' and 'Collections' sections, the Bun codebase is already prepared, using internal smart pointer types that map 1-to-1 to Rust equivalents,…

It's the same thing with their gcc stunt. It would be _so_ easy to alleviate any doubt from this and hype up the IPO even more. They just need start a separate repo with all the hidden work they needed to do to prod the AI along, and let everyone replicate the results. After all, isn't that what all their customers are trying to achieve? A million lines of usable code in "7" days? Never mind the fact that it will als…

Which part of a Zig to Rust port (working, passing tests) of a quite large codebase in a little over a week is not worthy of hype do you reckon? That they didn't one-shot it? What could possibly make it impressive if not the sheer velocity of the thing? That's a months or years long operation for a human. There's a reason porting large programs to new languages was vanishingly rare throughout most of computing history, and there's a reason people are suddenly doing it almost on a whim, now.

Re: Rewrite Bun in Rust has been merged

#670
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 will not go wrong in obvious ways, LLMs are actually not that bad for language translation, and they have big test coverage; any issues will be non obvious. The question will be more long term maintainability, how fast will the whole thing collapse.
Post reply on HN