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.
Rewrite Bun in Rust has been merged
661–670 of 822 posts
Re: Rewrite Bun in Rust has been merged
#662When 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,…
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
#663Re: Rewrite Bun in Rust has been merged
#664Earlier 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.
Re: Rewrite Bun in Rust has been merged
#665I'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…
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
#666Earlier 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.
Re: Rewrite Bun in Rust has been merged
#667Earlier 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
> 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
#668Earlier 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.
Re: Rewrite Bun in Rust has been merged
#669When 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…
Re: Rewrite Bun in Rust has been merged
#670If 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