4 ms·

Bun has been converted to rust. Now what?

53 points by jottinger 5mo ago

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 ago
  For 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 ago
    Sure, 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 ago
      Right, 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 ago
        For 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 ago
        They 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 ago
  Were "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 ago
      I 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 ago
  Preparation, 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 ago
  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)
  - mpalmer 5mo ago
    It's generally best to do several things that no one did here.
- dralley 5mo ago
  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.
- maipen 5mo ago
  I 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 ago
  Value to Anthropic's shareholders.
elnatro 5mo ago
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.
- scottcorgan 5mo ago
  yes
- julkali 5mo ago
  no
- deleted 5mo ago
  [deleted]
- amiga386 5mo ago
  hell no
- embedding-shape 5mo ago
  Current feedback says: "yes", "hell no" and "no" so I guess I'll add this so we come full circle: It depends.
- janderson215 5mo ago
  hell yes
- jillesvangurp 5mo ago
  If it has tests and responsible management, sure why not. I generally feel more comfortable if something is 1) widely used & scrutinized 2) managed competently. But that's orthogonal to how (not if) people use AI. Having good tests, reviews, etc. is much more important. Do people trust random NPMs developed by random people on the internet? Apparently we do given all the recent issues with supply chain attacks. I have a problem with people using vibe coding to refer to any contribution for which AI is used. I think it is inaccurate. People providing very low quality contributions to projects is a problem. But the real problem is people accepting such contributions.
lukeweston1234 5mo ago
Couple of notes here: - This is blatantly irresponsible, and killed any credibility this project has - Comparing unsafe counts to UV makes no sense here. - There is already a strong, safe runtime that's not vibe coded, called Deno, that more people need to check out. - I am skeptical why Bun was even an acquisition target in the first place, other than pulling stunts like this.
- jolux 5mo ago
  Claude Code uses Bun.
  - lioeters 5mo ago
    Why didn't they just rewrite Claude Code in Rust, and save everyone else the trouble of becoming the subject of their dramatic public experiment.
- nicce 5mo ago
  > - There is already a strong, safe runtime that's not vibe coded, called Deno, that more people need to check out. But people don't like the differences in the other feature parity. Otherwise they would already use it.
- lunar_mycroft 5mo ago
  > Comparing unsafe counts to UV makes no sense here. Agreed. The better comparison is Deno, which does roughly the same thing (wrapping a c/c++ javascript engine to create a serverside runtime). Deno was smaller, but per line of code/file it had just over half the unsafe as the bun slop rewrite. There are also examples of unsafe blocks that are just locally incorrect [0], meaning you don't even need to read outside the function and it's definition to determine that the entity doing the porting (in this case claude) didn't understand how unsafe rust works. > I am skeptical why Bun was even an acquisition target in the first place, other than pulling stunts like this. From what I've heard, it sounds like the author had become fully hooked by LLM coding before the acquisition, so I don't think we know enough to conclude that this was premeditated by Anthropic. I think the more likely trigger is that Bun had just bragged about how they'd forked the zig language for a performance increase and attacked zig for it's no-AI policy, only for a zig core team member to point out that the code couldn't be upstreamed even if it had been hand written [1]. The better point, IMO, is how this is an example of how AI use/addiction makes developers who fall into it loose the ability to judge code quality, particularly for code they prompted for themselves. From what I've heard of Mr. Sumner and the team at oven from before AI, I very much doubt code of this poor quality would have been allowed anywhere near the main branch before LLMs. [0] https://github.com/oven-sh/bun/blob/d2a6506dfad4c3ef3dddb9ae1adec875eb5734bd/src/bun_core/string/MutableString.rs#L413 https://github.com/oven-sh/bun/blob/d2a6506dfad4c3ef3dddb9ae... [1] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19 https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
Philpax 5mo ago
The irony of a post about a port primarily written by Claude having been primarily written by Claude on a website primarily designed by Claude. Come on.
- jottinger 5mo ago
  Claude (and Codex) designed the site, mostly because I'm not a UI coder; if I'd designed the site nobody'd want to read it but me, simply thanks to the UX. And I have a full-time job and more; I draft with an LLM's assistance and revise with another LLM (and other humans where possible) because I'm just arrogant enought o think that what I think might be useful to others. If it's not useful to you, I get it. Such is life.
  - ane 5mo ago
    Why can't you just publish the prompt instead? Do you not see how LLMs subtly alter your original message and erase your voice? They fill gaps that didn't exist, they create syllogisms that make no sense, and the voice is now so ridiculously AIdiosyncratic that it makes my eyes boil! If you have a message that takes 100 words to say, do not use a LLM to add 400 words to it, this isn't a school assignment! Stretching a spaghetti does not yield more spaghetti, it just makes a mess! Where is the value the LLM adds? Grammar? Vocabulary? The price you pay is you sound like everyone else and your original message is lost in the noise.
    - jottinger 5mo ago
      Heh. Funny thing: I've been writing online and professionally for literal decades, since around 2002 or so, and the LLMs tend to change my actual writing voice relatively little and usually in positive ways, since they say I meander too much.
    - jottinger 5mo ago
      As far as publishing "the prompt" - there's no "the prompt." The draft was put together and expanded over a set of interactions with an LLM and other people over the space of about six hours. "The prompt" would have been about twelve pages long and unreadable. Funny as heck, but unreadable. (If you're really interested, you can check the logs in the site and find the actual interaction that started the article out. It was a comment from someone else, and it got me thinking.)
reissbaker 5mo ago
We've come full circle: now we have AI-written blog posts complaining about AI-written code.
- tempodox 5mo ago
  I assume both are for an audience of bots.
simonw 5mo ago
> 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/c01a5e08be896e1d1f452981d50ea6e0b2e5b212 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 https://github.com/oven-sh/bun/pull/30680#event-25523046939
- jottinger 5mo ago
  Humans can make errors; part of why I waited so long to write and post this is because I'm not a great Rust coder (at all) and I don't use Bun, so I felt like I lacked enough relevant insight to say anything, and this is part of that, I think.
  - embedding-shape 5mo ago
    > Humans can make errors Sure, that makes sense, no one bats an eye over that. But this seems like a typical LLM hallucination, get the overall picture right, but misattributed where the actual work was done, this time it confused a GitHub feature for a feature of that particular repository, very common LLM mistake. I'd be curious to know, if you were actually the one who made this mistake, how it actually came about? When you looked into how the label/actions were working, how did you manage to confuse a Actions Workflow for a built-in GitHub feature?
    - jottinger 5mo ago
      Mostly because I finally figured out what I thought was relevant about the Bun port over the last couple of days, thanks to someone far more embedded in the ecosystem than I complaining about it. That complaint was the seed idea in the post, and shows up only remotely, because I thought the complaint itself was ranty and misplaced, but cast a shadow that actually interested me more. So I did some casual research, but used generalized numbers and impressions; I wasn't trying to pretend deep research, and some of the numbers (like the 99.8%) were drawn from publications and discussions that seemed not in debate. I am not an akshual journalist - I'm a systems architect who enjoys writing, who's served in a sort of journalistic role, and I sometimes write about topics that are not in my area of expertise. I don't write JS often myself; I've looked at Bun, particularly when it first came out, but my in-depth experience with it is minimal, so I'm writing everything from afar, and that includes the impression about the git interaction, which people wrote about and from which I inferred my conclusion, particularly because I didn't see the point of manually triggering the rejection.
embedding-shape 5mo ago
> 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.
- jottinger 5mo ago
  If I recall correctly - and I might not - the process found places in the test suite that were wrong or lacked clarity, and the suite was modified slightly in a few places to actually fix things that needed fixing. I don't think it was a broad enough change to actually significantly affect the coverage to a real degree, but then again, that WOULD be a good thing to dive into the PR to check - and as I've pointed out, I'm not a Bun user myself, so my main response to that is a vaguely-interested shrug and a nod towards what seems to be the bigger issue: the use of AI to do things performatively.
  - kangalioo 5mo ago
    In what sense was Bun's rewrite performative? If I recall correctly, Jarred deliberately tried to fly a bit under the radar to prevent the inevitable outcry
    - jottinger 5mo ago
      In the sense that while there was a positive outcome ("We moved to Rust, which solved our issues with Zig no longer accepting AI-assisted content" - a projection on my part, but one I think makes sense) without an actual contribution that one would expect. It's in Rust! That means Rust's memory safety applies! ... except as a direct port, it doesn't, it's got Zig's memory semantics in Rust-shaped code. As others have pointed out (including me, FWIW) that's something that can change... but it's not a simple thing to accomplish, and it may ALWAYS be a Zig-shaped skeleton in a bag of Rust.
voidUpdate 5mo ago
How much of an architectural change does the borrow checker require? It feels to me like a pretty central part of Rust, and you can't just translate all the files one to one, then refactor out the unsafe blocks, it might need a full think through and project analysis to make it actually work with rust, instead of being forced into rust
woodruffw 5mo ago
> For scale: uv, a Rust project of broadly comparable size from the same general corner of the ecosystem, contains 73. As a point of information: uv's use of `unsafe` largely involves interactions with OS APIs that don't have safe wrappers yet (in practice, this is mostly Win32 and similar APIs). It makes sense that Bun would have more `unsafe` than uv does, insofar as it needs to interact with JavaScriptCore's C API. (This is without making a value judgement; only to observe that the magnitude of `unsafe` across projects doesn't necessarily communicate anything without knowing what the `unsafe` is for.)
- zeroCalories 5mo ago
  I would trust a zig -> rust translation far less if it didn't make liberal use of unsafe, because that implies an order of magnitude more aggressive refactoring
- lunar_mycroft 5mo ago
  Bun has about twice the density of `unsafe` compared to deno, which does roughly the same job (wrap a c/c++ javascript engine to make a server side runtime written in rust). So not as massive a difference as the linked post's comparison, but still significantly more unsafe than we'd expect.
  - kangalioo 5mo ago
    I haven't heard that number before and I'm actually impressed. For a file-by-file close to literal translation of a memory-unsafe language to Rust, isn't that pretty good? I was expecting the post-rewrite Bun's unsafe usages to be in the order of magnitude of C2Rust (https://c2rust.com/ https://c2rust.com/). I was _not_ expecting it to be in the same ballpark as hand-written Rust.
    - lunar_mycroft 5mo ago
      I'm not sure I'd classify "double" as "the same ballpark", but either way C2Rust appears to just mark everything as `unsafe` (even when it's completely unnecessary), so I don't think that's a fair comparison. Further, I know for a fact that their are instances of the `unsafe` in the bun codebase right now that are just trivially incorrect in rust. A vaguely competent human programmer, even one doing a 1:1 translation (which is likely a bad idea anyway) would have caught those.
ksec 5mo ago
I am idly wondering, would it have made a difference if this was done over a month or two rather than say 9 days. If it was really a thought experiment, and the test suit was so good, and hopefully further improved after this. Could the same experiment be run translating to Go, C, C++, Pascal, Swift, Crystal or Ada?
a-dub 5mo ago
if anything, compilers and interpreters are probably the most suited for ai codegen as they have some of the most comprehensive test suites around and are relatively easy to verify. that said, it's a fun debate. sure, the rust compiler eliminated a whole class of memory bugs- but did the convoluted borrow checker gymnastics plus agent whoopsiedaisies leave behind a plethora of hidden and exploitable logic bugs? it'll be interesting to see, although we may never know as anthropic will probably use the latest frontier models to audit and quietly patch over the coming years.
petesergeant 5mo ago
This feels confused. The point is surely that memory-safe code can now be written, where the article seems to focus on the fact that it hasn't been yet.
- lunar_mycroft 5mo ago
  Yes and no. In theory, you could start to go through an factor out unnecessary unsafe blocks from the codebase now. In practice, writing safe rust often requires significantly different design decisions than writing in garbage collected or fully manually memory managed languages, especially if you want the results to be performant. There's a very good chance you'd be better off rewriting from scratch than trying to do a 1:1 translation/port.
losvedir 5mo ago
I don't understand why they ported the Zig part. Wouldn't it have made more sense to have just unleashed the tokens on Claude Code itself, and eliminated the need for the bundled runtime altogether?
fg137 5mo ago
I always thought if they are vibe coding all the unsafe Rust code, they might as well keep it in zig, at least someone understands what they are doing. With Rust, when there is a CVE, chances are that nobody can even understand what the issue is, let alone fixing it. I for one am definitely going to stick to Node.js instead of taking my chances with Bun.
jt2190 5mo ago
> This is a measurement discipline: when someone offers you a test pass rate as evidence of a safety property, check whether the test suite measures that property. Behavioral equivalence and memory soundness are different axes. A green test suite tells you the new thing acts like the old thing. If the old thing was a body of manual memory management and the new thing is a faithful translation of it, then green tells you the translation is good - and tells you nothing whatsoever about whether the thing is safe. The number that would actually answer the question is the one nobody can produce yet, because producing it is, for now, an unsolved problem. Bottom line is we didn’t have a measurement of safety before the port, and we don’t have one now. What we do have is a known list of unsafe blocks, and we can use that as our safety measure. (I’m neither a Zig not Rust programmer, but I’m guessing that the unsafe parts of the Zig codebase were also mostly measurable so we could have had this measure.) I do wonder if the next step is to move bun into WASM for an additional layer of security. Those unsafe blocks might be neutered by not granting WASM the ability to run them. That would give anthropic a “sandboxed by default” opportunity. It’s a fun project to watch!
ianm218 5mo ago
Posted this in a thread yesterday but seems relevant, I have been working on similar open source rewrites. Starting with Lua and Nginx. Trying to target idiomatic/ performant safe Rust from the start than straight porting and adding safety/ performance later. - Valkey/ Redis port here https://github.com/ianm199/valdr https://github.com/ianm199/valdr (passes ~99% of single node test suite, real prod features like replication/ clustering/ HA early or not implemented) - Further along port of Lua 5.1-5.5 https://github.com/ianm199/lua-rs-port/tree/main https://github.com/ianm199/lua-rs-port/tree/main - I have a less developed nginx version that would be the North Star - These projects are very alpha at the moment. The thought was that we might need many “shots on net” in terms of software safety in the future so worth exploring.
pxtail 5mo ago
So who will be doing upkeep and maintenance of the project, will developers who worked on this project need to learn Rust to be able to work with the codebase and be able to have correct judgement about changes done by LLM? If yes then will junior Rust developers be able to correctly assess PR's generated by LLM? Or developers will be fired and new team with Rust expertise will be responsible for the project now?
cpursley 5mo ago
Well, that’s an easy one: start converting all the node dumpster fires into rust as well. Especially the electron apps…
sargstuff 5mo ago
Food for thought: Add a lambda fuction. Add list of condiments[0] such as let-us. Forage/prove one can have a turing complete meal with bun? Easier than risking indigestion through bun/sheaf correspondence.[1][2][3][4] ------------------------------------ [0] : https://en.wikipedia.org/wiki/List_of_condiments https://en.wikipedia.org/wiki/List_of_condiments [1] : Applied Sheaf Theory for Multi-agent Arificial Intelligence (Reinforcement Learnig) Systems: A prospectus : https://people.cs.uchicago.edu/~ericschmid/schmid-applied-sheaf-theory.pdf https://people.cs.uchicago.edu/~ericschmid/schmid-applied-sh... [2] : Discreate Morse theory for computing cellular sheaf cohomology : https://www2.math.upenn.edu/~ghrist/preprints/computationalsheafcohom.pdf https://www2.math.upenn.edu/~ghrist/preprints/computationals... [3] : https://medium.com/@german_mag.ai/sheaf-theory-and-applications-e0c32e9110f4 https://medium.com/@german_mag.ai/sheaf-theory-and-applicati... [4] : https://direct.mit.edu/books/oa-monograph/5460/Sheaf-Theory-through-Examples https://direct.mit.edu/books/oa-monograph/5460/Sheaf-Theory-...
classified 5mo ago
You now need a carry permit and a casino license to run bun because it has become indistinguishable from Russian roulette.
justinsaccount 5mo ago
> The Zig implementation that powered Bun is gone. The Zig implementation is literally still there. You can make predictions of what might happen in the future, but hard to take the rest of the article seriously when it has the basic facts wrong.
pepa65 5mo ago
What has not been talked about here yet, and which isn't directly about AI, is this: "The benchmarks are neutral-to-faster, and the binary shrank by a few megabytes" This says more about Zig versus Rust, and I was surprised by it, that a "direct translation" of this kind would give a somewhat faster and smaller binary.

53 points 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 ago
For 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 ago
  Sure, 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 ago
    Right, 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 ago
      For 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 ago
        They 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 ago
Were "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 ago
    I 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 ago
Preparation, 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 ago
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)
- mpalmer 5mo ago
  It's generally best to do several things that no one did here.
dralley 5mo ago
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.
maipen 5mo ago
I 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 ago
Value to Anthropic's shareholders.

elnatro 5mo ago

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.

scottcorgan 5mo ago
yes
julkali 5mo ago
no
deleted 5mo ago
[deleted]
amiga386 5mo ago
hell no
embedding-shape 5mo ago
Current feedback says: "yes", "hell no" and "no" so I guess I'll add this so we come full circle: It depends.
janderson215 5mo ago
hell yes
jillesvangurp 5mo ago
If it has tests and responsible management, sure why not. I generally feel more comfortable if something is 1) widely used & scrutinized 2) managed competently. But that's orthogonal to how (not if) people use AI. Having good tests, reviews, etc. is much more important. Do people trust random NPMs developed by random people on the internet? Apparently we do given all the recent issues with supply chain attacks. I have a problem with people using vibe coding to refer to any contribution for which AI is used. I think it is inaccurate. People providing very low quality contributions to projects is a problem. But the real problem is people accepting such contributions.

lukeweston1234 5mo ago

Couple of notes here: - This is blatantly irresponsible, and killed any credibility this project has - Comparing unsafe counts to UV makes no sense here. - There is already a strong, safe runtime that's not vibe coded, called Deno, that more people need to check out. - I am skeptical why Bun was even an acquisition target in the first place, other than pulling stunts like this.

jolux 5mo ago
Claude Code uses Bun.
- lioeters 5mo ago
  Why didn't they just rewrite Claude Code in Rust, and save everyone else the trouble of becoming the subject of their dramatic public experiment.
nicce 5mo ago
> - There is already a strong, safe runtime that's not vibe coded, called Deno, that more people need to check out. But people don't like the differences in the other feature parity. Otherwise they would already use it.
lunar_mycroft 5mo ago
> Comparing unsafe counts to UV makes no sense here. Agreed. The better comparison is Deno, which does roughly the same thing (wrapping a c/c++ javascript engine to create a serverside runtime). Deno was smaller, but per line of code/file it had just over half the unsafe as the bun slop rewrite. There are also examples of unsafe blocks that are just locally incorrect [0], meaning you don't even need to read outside the function and it's definition to determine that the entity doing the porting (in this case claude) didn't understand how unsafe rust works. > I am skeptical why Bun was even an acquisition target in the first place, other than pulling stunts like this. From what I've heard, it sounds like the author had become fully hooked by LLM coding before the acquisition, so I don't think we know enough to conclude that this was premeditated by Anthropic. I think the more likely trigger is that Bun had just bragged about how they'd forked the zig language for a performance increase and attacked zig for it's no-AI policy, only for a zig core team member to point out that the code couldn't be upstreamed even if it had been hand written [1]. The better point, IMO, is how this is an example of how AI use/addiction makes developers who fall into it loose the ability to judge code quality, particularly for code they prompted for themselves. From what I've heard of Mr. Sumner and the team at oven from before AI, I very much doubt code of this poor quality would have been allowed anywhere near the main branch before LLMs. [0] https://github.com/oven-sh/bun/blob/d2a6506dfad4c3ef3dddb9ae1adec875eb5734bd/src/bun_core/string/MutableString.rs#L413 https://github.com/oven-sh/bun/blob/d2a6506dfad4c3ef3dddb9ae... [1] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19 https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Philpax 5mo ago

The irony of a post about a port primarily written by Claude having been primarily written by Claude on a website primarily designed by Claude. Come on.

jottinger 5mo ago
Claude (and Codex) designed the site, mostly because I'm not a UI coder; if I'd designed the site nobody'd want to read it but me, simply thanks to the UX. And I have a full-time job and more; I draft with an LLM's assistance and revise with another LLM (and other humans where possible) because I'm just arrogant enought o think that what I think might be useful to others. If it's not useful to you, I get it. Such is life.
- ane 5mo ago
  Why can't you just publish the prompt instead? Do you not see how LLMs subtly alter your original message and erase your voice? They fill gaps that didn't exist, they create syllogisms that make no sense, and the voice is now so ridiculously AIdiosyncratic that it makes my eyes boil! If you have a message that takes 100 words to say, do not use a LLM to add 400 words to it, this isn't a school assignment! Stretching a spaghetti does not yield more spaghetti, it just makes a mess! Where is the value the LLM adds? Grammar? Vocabulary? The price you pay is you sound like everyone else and your original message is lost in the noise.
  - jottinger 5mo ago
    Heh. Funny thing: I've been writing online and professionally for literal decades, since around 2002 or so, and the LLMs tend to change my actual writing voice relatively little and usually in positive ways, since they say I meander too much.
  - jottinger 5mo ago
    As far as publishing "the prompt" - there's no "the prompt." The draft was put together and expanded over a set of interactions with an LLM and other people over the space of about six hours. "The prompt" would have been about twelve pages long and unreadable. Funny as heck, but unreadable. (If you're really interested, you can check the logs in the site and find the actual interaction that started the article out. It was a comment from someone else, and it got me thinking.)

reissbaker 5mo ago

We've come full circle: now we have AI-written blog posts complaining about AI-written code.

tempodox 5mo ago
I assume both are for an audience of bots.

simonw 5mo ago

> 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/c01a5e08be896e1d1f452981d50ea6e0b2e5b212 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 https://github.com/oven-sh/bun/pull/30680#event-25523046939

jottinger 5mo ago
Humans can make errors; part of why I waited so long to write and post this is because I'm not a great Rust coder (at all) and I don't use Bun, so I felt like I lacked enough relevant insight to say anything, and this is part of that, I think.
- embedding-shape 5mo ago
  > Humans can make errors Sure, that makes sense, no one bats an eye over that. But this seems like a typical LLM hallucination, get the overall picture right, but misattributed where the actual work was done, this time it confused a GitHub feature for a feature of that particular repository, very common LLM mistake. I'd be curious to know, if you were actually the one who made this mistake, how it actually came about? When you looked into how the label/actions were working, how did you manage to confuse a Actions Workflow for a built-in GitHub feature?
  - jottinger 5mo ago
    Mostly because I finally figured out what I thought was relevant about the Bun port over the last couple of days, thanks to someone far more embedded in the ecosystem than I complaining about it. That complaint was the seed idea in the post, and shows up only remotely, because I thought the complaint itself was ranty and misplaced, but cast a shadow that actually interested me more. So I did some casual research, but used generalized numbers and impressions; I wasn't trying to pretend deep research, and some of the numbers (like the 99.8%) were drawn from publications and discussions that seemed not in debate. I am not an akshual journalist - I'm a systems architect who enjoys writing, who's served in a sort of journalistic role, and I sometimes write about topics that are not in my area of expertise. I don't write JS often myself; I've looked at Bun, particularly when it first came out, but my in-depth experience with it is minimal, so I'm writing everything from afar, and that includes the impression about the git interaction, which people wrote about and from which I inferred my conclusion, particularly because I didn't see the point of manually triggering the rejection.

embedding-shape 5mo ago

> 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.

jottinger 5mo ago
If I recall correctly - and I might not - the process found places in the test suite that were wrong or lacked clarity, and the suite was modified slightly in a few places to actually fix things that needed fixing. I don't think it was a broad enough change to actually significantly affect the coverage to a real degree, but then again, that WOULD be a good thing to dive into the PR to check - and as I've pointed out, I'm not a Bun user myself, so my main response to that is a vaguely-interested shrug and a nod towards what seems to be the bigger issue: the use of AI to do things performatively.
- kangalioo 5mo ago
  In what sense was Bun's rewrite performative? If I recall correctly, Jarred deliberately tried to fly a bit under the radar to prevent the inevitable outcry
  - jottinger 5mo ago
    In the sense that while there was a positive outcome ("We moved to Rust, which solved our issues with Zig no longer accepting AI-assisted content" - a projection on my part, but one I think makes sense) without an actual contribution that one would expect. It's in Rust! That means Rust's memory safety applies! ... except as a direct port, it doesn't, it's got Zig's memory semantics in Rust-shaped code. As others have pointed out (including me, FWIW) that's something that can change... but it's not a simple thing to accomplish, and it may ALWAYS be a Zig-shaped skeleton in a bag of Rust.

voidUpdate 5mo ago

How much of an architectural change does the borrow checker require? It feels to me like a pretty central part of Rust, and you can't just translate all the files one to one, then refactor out the unsafe blocks, it might need a full think through and project analysis to make it actually work with rust, instead of being forced into rust

woodruffw 5mo ago

> For scale: uv, a Rust project of broadly comparable size from the same general corner of the ecosystem, contains 73. As a point of information: uv's use of `unsafe` largely involves interactions with OS APIs that don't have safe wrappers yet (in practice, this is mostly Win32 and similar APIs). It makes sense that Bun would have more `unsafe` than uv does, insofar as it needs to interact with JavaScriptCore's C API. (This is without making a value judgement; only to observe that the magnitude of `unsafe` across projects doesn't necessarily communicate anything without knowing what the `unsafe` is for.)

zeroCalories 5mo ago
I would trust a zig -> rust translation far less if it didn't make liberal use of unsafe, because that implies an order of magnitude more aggressive refactoring
lunar_mycroft 5mo ago
Bun has about twice the density of `unsafe` compared to deno, which does roughly the same job (wrap a c/c++ javascript engine to make a server side runtime written in rust). So not as massive a difference as the linked post's comparison, but still significantly more unsafe than we'd expect.
- kangalioo 5mo ago
  I haven't heard that number before and I'm actually impressed. For a file-by-file close to literal translation of a memory-unsafe language to Rust, isn't that pretty good? I was expecting the post-rewrite Bun's unsafe usages to be in the order of magnitude of C2Rust (https://c2rust.com/ https://c2rust.com/). I was _not_ expecting it to be in the same ballpark as hand-written Rust.
  - lunar_mycroft 5mo ago
    I'm not sure I'd classify "double" as "the same ballpark", but either way C2Rust appears to just mark everything as `unsafe` (even when it's completely unnecessary), so I don't think that's a fair comparison. Further, I know for a fact that their are instances of the `unsafe` in the bun codebase right now that are just trivially incorrect in rust. A vaguely competent human programmer, even one doing a 1:1 translation (which is likely a bad idea anyway) would have caught those.

ksec 5mo ago

I am idly wondering, would it have made a difference if this was done over a month or two rather than say 9 days. If it was really a thought experiment, and the test suit was so good, and hopefully further improved after this. Could the same experiment be run translating to Go, C, C++, Pascal, Swift, Crystal or Ada?

a-dub 5mo ago

if anything, compilers and interpreters are probably the most suited for ai codegen as they have some of the most comprehensive test suites around and are relatively easy to verify. that said, it's a fun debate. sure, the rust compiler eliminated a whole class of memory bugs- but did the convoluted borrow checker gymnastics plus agent whoopsiedaisies leave behind a plethora of hidden and exploitable logic bugs? it'll be interesting to see, although we may never know as anthropic will probably use the latest frontier models to audit and quietly patch over the coming years.

petesergeant 5mo ago

This feels confused. The point is surely that memory-safe code can now be written, where the article seems to focus on the fact that it hasn't been yet.

lunar_mycroft 5mo ago
Yes and no. In theory, you could start to go through an factor out unnecessary unsafe blocks from the codebase now. In practice, writing safe rust often requires significantly different design decisions than writing in garbage collected or fully manually memory managed languages, especially if you want the results to be performant. There's a very good chance you'd be better off rewriting from scratch than trying to do a 1:1 translation/port.

losvedir 5mo ago

I don't understand why they ported the Zig part. Wouldn't it have made more sense to have just unleashed the tokens on Claude Code itself, and eliminated the need for the bundled runtime altogether?

fg137 5mo ago

I always thought if they are vibe coding all the unsafe Rust code, they might as well keep it in zig, at least someone understands what they are doing. With Rust, when there is a CVE, chances are that nobody can even understand what the issue is, let alone fixing it. I for one am definitely going to stick to Node.js instead of taking my chances with Bun.

jt2190 5mo ago

> This is a measurement discipline: when someone offers you a test pass rate as evidence of a safety property, check whether the test suite measures that property. Behavioral equivalence and memory soundness are different axes. A green test suite tells you the new thing acts like the old thing. If the old thing was a body of manual memory management and the new thing is a faithful translation of it, then green tells you the translation is good - and tells you nothing whatsoever about whether the thing is safe. The number that would actually answer the question is the one nobody can produce yet, because producing it is, for now, an unsolved problem. Bottom line is we didn’t have a measurement of safety before the port, and we don’t have one now. What we do have is a known list of unsafe blocks, and we can use that as our safety measure. (I’m neither a Zig not Rust programmer, but I’m guessing that the unsafe parts of the Zig codebase were also mostly measurable so we could have had this measure.) I do wonder if the next step is to move bun into WASM for an additional layer of security. Those unsafe blocks might be neutered by not granting WASM the ability to run them. That would give anthropic a “sandboxed by default” opportunity. It’s a fun project to watch!

ianm218 5mo ago

Posted this in a thread yesterday but seems relevant, I have been working on similar open source rewrites. Starting with Lua and Nginx. Trying to target idiomatic/ performant safe Rust from the start than straight porting and adding safety/ performance later. - Valkey/ Redis port here https://github.com/ianm199/valdr https://github.com/ianm199/valdr (passes ~99% of single node test suite, real prod features like replication/ clustering/ HA early or not implemented) - Further along port of Lua 5.1-5.5 https://github.com/ianm199/lua-rs-port/tree/main https://github.com/ianm199/lua-rs-port/tree/main - I have a less developed nginx version that would be the North Star - These projects are very alpha at the moment. The thought was that we might need many “shots on net” in terms of software safety in the future so worth exploring.

pxtail 5mo ago

So who will be doing upkeep and maintenance of the project, will developers who worked on this project need to learn Rust to be able to work with the codebase and be able to have correct judgement about changes done by LLM? If yes then will junior Rust developers be able to correctly assess PR's generated by LLM? Or developers will be fired and new team with Rust expertise will be responsible for the project now?

cpursley 5mo ago

Well, that’s an easy one: start converting all the node dumpster fires into rust as well. Especially the electron apps…

sargstuff 5mo ago

Food for thought: Add a lambda fuction. Add list of condiments[0] such as let-us. Forage/prove one can have a turing complete meal with bun? Easier than risking indigestion through bun/sheaf correspondence.[1][2][3][4] ------------------------------------ [0] : https://en.wikipedia.org/wiki/List_of_condiments https://en.wikipedia.org/wiki/List_of_condiments [1] : Applied Sheaf Theory for Multi-agent Arificial Intelligence (Reinforcement Learnig) Systems: A prospectus : https://people.cs.uchicago.edu/~ericschmid/schmid-applied-sheaf-theory.pdf https://people.cs.uchicago.edu/~ericschmid/schmid-applied-sh... [2] : Discreate Morse theory for computing cellular sheaf cohomology : https://www2.math.upenn.edu/~ghrist/preprints/computationalsheafcohom.pdf https://www2.math.upenn.edu/~ghrist/preprints/computationals... [3] : https://medium.com/@german_mag.ai/sheaf-theory-and-applications-e0c32e9110f4 https://medium.com/@german_mag.ai/sheaf-theory-and-applicati... [4] : https://direct.mit.edu/books/oa-monograph/5460/Sheaf-Theory-through-Examples https://direct.mit.edu/books/oa-monograph/5460/Sheaf-Theory-...

classified 5mo ago

You now need a carry permit and a casino license to run bun because it has become indistinguishable from Russian roulette.

justinsaccount 5mo ago

> The Zig implementation that powered Bun is gone. The Zig implementation is literally still there. You can make predictions of what might happen in the future, but hard to take the rest of the article seriously when it has the basic facts wrong.

pepa65 5mo ago

What has not been talked about here yet, and which isn't directly about AI, is this: "The benchmarks are neutral-to-faster, and the binary shrank by a few megabytes" This says more about Zig versus Rust, and I was surprised by it, that a "direct translation" of this kind would give a somewhat faster and smaller binary.