4 ms·
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 reaso
by jottinger 5mo ago
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?
- jakelazaroff 5mo agoFor one, you now know exactly where the memory unsafe code is, rather than a cloud of suspicion hanging over every line of the codebase.
- gspr 5mo agoSure, as long as all the code in all those unsafe blocks is sound! If not, the program is UB and all bets are off for every line of the codebase. I think Rust strikes a perfect balance between a safe default and, as you say, "localized unsafety". Said localized unsafety is however only localized as long as you're "doing it right". I would absolutely not trust an LLM to do it right for hundreds of thousands of lines of translated code. This is insane.
- jakelazaroff 5mo agoRight, but the point is that you now have an explicit todo list of blocks to fix. You can trivially enumerate all sources of unsafety, and when a grep for unsafe blocks turns up empty you know your codebase is memory safe. When could you say the same about your Zig or C/C++ codebase? I'm writing this as someone who doesn't even really like Rust; I'd probably prefer to write Zig! But those unsafe blocks definitely buy you something.
- gspr 5mo agoFor normal use of unsafe in Rust, I completely agree, and I love the concept. But if you have a gazillion unsafe blocks written by someone (something) you don't trust to at least try to do the right thing, you're bound to have unsoundness in one of those blocks. And now your entire codebase is UB. I don't see how this is any different from every line trailing with a comment of the form "FIXME: This line might be wrong". And I say this as something of a Rust fanboy. I love the way unsafe blocks work, and the "locality of danger" they give you. But that all goes out the window if there's a gazillion haphazardly written such blocks.
- jakelazaroff 5mo agoThey have a gazillion such blocks today. If they still have a gazillion such blocks in a year, sure. But presumably the plan is to replace them with safe Rust.
- ivanjermakov 5mo agoWere "passing tests" also generated by the same LLM? This is much different from how Ladybird team handled a rewrite: https://news.ycombinator.com/item?id=47120899 https://news.ycombinator.com/item?id=47120899
- simonw 5mo ago> Were "passing tests" also generated by the same LLM? No. The useful thing about porting a language runtime is that most of the tests are written in the language that it's a runtime for, not the implementation language. It's very easy to catch if the coding agent rewrites those tests.
- ivanjermakov 5mo agoI heard that Bun is not just a JS runtime, but much more than that. JavaScriptCore (JS engine Bun uses) is property tested outside of Bun anyways, what about other stuff?
- ramon156 5mo agoPreparation, but this is prep for a scale that the maintainer is going to solve by more LLM-assisted coding, probably. Unsafe blocks are not inherently bad, but it's good that these are explicit unsafe blocks. It's like saying TODO comments are bad. It depends.
- 15155 5mo ago- A substantially simpler, more-contained build process - A base from which to build upon by removing unsafe blocks
- gspr 5mo ago> - A base from which to build upon by removing unsafe blocks This is nonsense if those unsafe blocks are unsound to begin with.
- rcxdude 5mo agoIt'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)
- mpalmer 5mo agoIt's generally best to do several things that no one did here.
- dralley 5mo agoConsidering 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.
- maipen 5mo agoI see comments like this and they seem so pointless. The port was done in a week. Do you think the development is finished? Obviously there are some unsafe blocks that will remain forever unsafe. But other will eventually be removed. Just a bunch of fearmongering
- onlyrealcuzzo 5mo ago> So what did the rewrite actually accomplish? Hype. On an aside, isn't Zig supposed to have much faster compile times than Rust, and didn't they give that as the main reason Zig wasn't working for them and why they wanted to switch to Rust? The whole thing seems insane. I don't know why anyone would switch to Rust for any reason besides the obvious: to get REAL memory safety. If you're doing that... You wouldn't wrap ~90% of your important code in `unsafe` blocks. You're doing a ton of work for virtually no benefit, and - if anything - a lot of negatives. Everything I've read and heard about this port raises more questions than answers, and not in a good way.
- nicce 5mo ago> So what did the rewrite actually accomplish? Great marketing stunt for Claude Code. Let's see later what is the result. But IPO is already over then...
- throw7 5mo agoValue to Anthropic's shareholders.