The follow-up PR removing the zig source files being auto-tagged by bun's own CI as "ai slop" is so funny https://github.com/oven-sh/bun/pull/30680
Rewrite Bun in Rust has been merged
101–110 of 822 posts
Re: Rewrite Bun in Rust has been merged
#102Re: Rewrite Bun in Rust has been merged
#103I'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…
Re: Rewrite Bun in Rust has been merged
#104Still 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…
Re: Rewrite Bun in Rust has been merged
#105Re: Rewrite Bun in Rust has been merged
#106So the geniuses in the datacenter prefer to rewrite the full codebase in another language instead of maintaining and improving its own fork or contributing to make the current language better. Impressive to rewrite 1MLOC in a week yes, but this is more of a job of a million monkey programmers crammed in a datacenter than a bunch geniuses. And I would know, since I'm a monkey programmer who is in danger now... Or mayb…
No matter how I look at this, it's churn for the sake of churn. Even if the translation was free and into ideal idiomatic Rust (and it's obviously not - it's now Zig with Rust syntax) then this would be churn for the sake of churn. At some project scale the language really stops being any limiting factor, and you're instead mostly dealing with working past past architectural decisions, integration of large changes, d…
Re: Rewrite Bun in Rust has been merged
#107Say what you want, but for people building products on Bun, this is bad news for the foreseeable future.
I don't understand the rationale behind how any project, especially of this magnitude, can seriously build something stable this way.
My consolation - and it could be pure cope - is that at least I am in the same boat as a huge company like Anthropic, and they surely wouldn't be stupid enough to also build their cli tools around something that they saw as risky.
feelsbadman.
Re: Rewrite Bun in Rust has been merged
#108Turns out "its just an experiment, you all are overreacting" was just a lie to damp criticism. https://news.ycombinator.com/item?id=48019226
It seems it was an experiment at that moment, and that it went well? I do hope they release it under 2.x though, cannot imagine how a 1M LoC can break in so many ways, especially if what xiphias says is true: https://news.ycombinator.com/item?id=48132902
Re: Rewrite Bun in Rust has been merged
#109Earlier quoted context omitted.
No matter how I look at this, it's churn for the sake of churn. Even if the translation was free and into ideal idiomatic Rust (and it's obviously not - it's now Zig with Rust syntax) then this would be churn for the sake of churn. At some project scale the language really stops being any limiting factor, and you're instead mostly dealing with working past past architectural decisions, integration of large changes, d…
The "idiomatic Rust" thing rubs me the wrong way. If someone writes Rust that compiles and works, that's Rust. full stop. Telling people it doesn't count until it's "idiomatic" is just gatekeeping. It quietly says you're not a real Rust dev until you've put in years and absorbed all the unwritten rules, which shuts out exactly the people who are still learning. Everyone writes "non-idiomatic" code when they start. Th…
Not that only idiomatic Rust is appropriate.
Re: Rewrite Bun in Rust has been merged
#110Still 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…