Bun has been converted to rust. Now what?(bytecode.news) |
Bun has been converted to rust. Now what?(bytecode.news) |
Would you trust a fully vibe-coded runtime? Not some features, not some fixes, but a full translation from one language to another.
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.
It depends.
We called it Adatran.
That code was weird and very hard to maintain. That goodness it was just small functions.
IMO, the main problem with vibe coding is that it empowers reckless behavior at companies like Microsoft, and that people with no serious investment in outcomes are empowered to make things. Does that apply to Anthropic? The Bun team? It's not 100% clear yet.
Human architects and engineers make TONS of mistakes in these designs all the time. Then builders and contractors fix them, or in many cases "fix" them, as I'm sure most people here have experienced.
Also if vibecoding houses can lead to a large increase in housing supply, as it should: Hurray!
If y'all ever wondered how your dads got sucked into alt right talkshows and radio, just read ops comment in Tucker Carlson's voice.
And you bringing the fringe entertainers of the illiterate Americans is totally unnecessary.
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.
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.)
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/). I was _not_ expecting it to be in the same ballpark as hand-written Rust.
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!
- Valkey/ Redis port here 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
- 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.
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
[1] : Applied Sheaf Theory for Multi-agent Arificial Intelligence (Reinforcement Learnig) Systems: A prospectus : 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/computationals...
[3] : https://medium.com/@german_mag.ai/sheaf-theory-and-applicati...
[4] : https://direct.mit.edu/books/oa-monograph/5460/Sheaf-Theory-...
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/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
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?
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.
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?
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.
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.
- 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.
I for one am definitely going to stick to Node.js instead of taking my chances with Bun.
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.
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.
The issue is the quippy titles, “something - aside - continue” phrasing, and other constructions are feel like they or actually are wholly LLM written. I find a high correlation to this and low density fluff. The author did not have 10 paragraphs of things to say, but used an LLM to inflate a short outline to that. We would all of been better off with a tighter document - either human written or better prompted.
These days due to usage of LLMs I developed (unknowingly) an LLM detector when reading these. I actually get distracted.
So please, I believe you do have something to tell to the world, but please take it slower. No need to rush. I'd rather have something to read uniquely made by you.
For your workflow, I'd suggest drafting with a LLM to help you find the right balance of content, and then throwing all of that out and writing it yourself. Otherwise, it won't sound like you.
But people don't like the differences in the other feature parity. Otherwise they would already use it.
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/d2a6506dfad4c3ef3dddb9ae...
[1] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
This is much different from how Ladybird team handled a rewrite: https://news.ycombinator.com/item?id=47120899
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.
And if nothing else Rust forces you to document where they are, which isn't nothing.
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.
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.
Great marketing stunt for Claude Code. Let's see later what is the result. But IPO is already over then...
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.
- A base from which to build upon by removing unsafe blocks
This is nonsense if those unsafe blocks are unsound to begin with.
Just a bunch of fearmongering
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.
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.
I love how well this captures the credibility of zealots and how some won't hesitate to exploit human suffering to push an agenda. The housing crisis is driven by regulation that lowers supply, shaped by greed and cruelty. Turning house designs into slop won't solve anything.
You want to see how AI actually contributes to the housing crisis? Then here's an actual example:
"Rent Going Up? One Company’s Algorithm Could Be Why." https://www.propublica.org/article/yieldstar-rent-increase-r...
(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.)
Sure, but that wasn't really the question, the question was why it's obvious no-one or no-thing have closely reviewed the code? Given they use LLMs to produce the code, wouldn't surprise me if they used LLMs to review it too, and I don't see it as unfeasible to be able to review a lot of code on a lot shorter timeframe.
It's not like they're doing something unique or novel, they even had an implementation in another language they knew did the right thing, so all the review would have to do, would be to make sure it's the same in the new language.
Don't get me wrong, again, probably there is plenty of mistakes in there, and might catch on fire when run in the wrong way, but I still don't think it's obvious how they've done things, unless you have insights into their process which seems clear to me now that you don't.
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.
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.
> They obviously haven't closely reviewed the code. That's the point
You asked why.
If Bun’s maintainers truly reviewed it, they would've had to read at least 6k lines per hour for a full week without a break. No one can claim in good faith that could possibly have happened.
Bun is now a black box consisting of million lines of largely unread code. No amount of "you don't know the whole story" lawyering or endless demands for "proof" of the obvious will change that.
The scope of the issue goes far deeper than "there might be some mistakes." Because what happened with the rewrite isn't engineering. Engineering applies the scientific method and rigorous verification to real world problems. It surely isn't about trusting a digital genie's "guarantees" that "all is fine." All aspects of LLM output is undefined behavior, and Bun blindly accepted million lines of code generated from it.
Before anyone brings it up again, tests aren't a sufficient defense. They only catch a tiny subset of the infinite possible failures. Modern software development still depends on developers understanding the code they produce.
Are you an engineer? Make clear claims, and then back then up crisp and concrete arguments. Support your arguments with data. That's engineering.
What you're doing is wallowing in the outrage machine. Please start with your indepth understanding of the bun runtime that qualifies you to comment on the overall quality claims that you have not yet made but have insinuated.
Please clearly cite your concerns. Please present a cogent and articulate analysis of the overall shortcomings, gaps and potential threats of the bun rewrite.
Let's have an engineering discussion.
And while you're at it, make your own argument. That's a skill required of any engineer.
The maintainers have merged an enormous pull request in a week. They haven’t shown signs of understanding Rust. They are doing an experiment that can affect (via runtime bugs) to all bun users.