Live data from Hacker News

How is the Bun rewrite in Rust going?

lockwood.dev

371–380 of 412 posts

Re: How is the Bun rewrite in Rust going?

#371
post #148

Bun’s Rust rewrite shipped in Claude Code over a month ago and barely anyone noticed. Claude Code is widely used. The Rust rewrite is going well overall. In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likel…

Ok, so you've just admitted that you have deployed thousands of lines of likely non-human reviewed LLM generated code (Bun's rust rewrite) to millions of client machines (via the Claude Code app auto-update) with significant local client access credentials, in a relatively quick and rushed manner. What's stopping the LLM from having unscrupulously injected something nefarious into the codebase that you are unaware of…

Claude Code has been written with Claude Code for a long time - that ship has long sailed.

Re: How is the Bun rewrite in Rust going?

#372
post #148

Bun’s Rust rewrite shipped in Claude Code over a month ago and barely anyone noticed. Claude Code is widely used. The Rust rewrite is going well overall. In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likel…

Ok, so you've just admitted that you have deployed thousands of lines of likely non-human reviewed LLM generated code (Bun's rust rewrite) to millions of client machines (via the Claude Code app auto-update) with significant local client access credentials, in a relatively quick and rushed manner. What's stopping the LLM from having unscrupulously injected something nefarious into the codebase that you are unaware of…

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

I guess they put it in capitals for a reason.

Re: How is the Bun rewrite in Rust going?

#373

Earlier quoted context omitted.

Ok, so you've just admitted that you have deployed thousands of lines of likely non-human reviewed LLM generated code (Bun's rust rewrite) to millions of client machines (via the Claude Code app auto-update) with significant local client access credentials, in a relatively quick and rushed manner. What's stopping the LLM from having unscrupulously injected something nefarious into the codebase that you are unaware of…

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR TH…

"I put it in the terms of use, so I am not responsible for what my poorly developer software does" only goes so far.

It could be argued, probably successfully, that this is a case of gross negligence and that Anthropic should be held accountable for harm caused due to their reckless actions.

Especially now that they have been made aware of the possibility, they also cannot claim ignorance of the potential issues.

Certain consumer rights, depending upon the country, also cannot simply be removed or waived due to a organisation's terms of use or implied contract.

Re: How is the Bun rewrite in Rust going?

#374

Earlier quoted context omitted.

Why is porting a program from one language to another seen as some great achievement? We had f2c in the 1990s. https://en.wikipedia.org/wiki/F2c

This isn't a valid comparison. f2c is a compiler and the output isn't intended to be human readable.

Plenty of people telling us not to bother reading code output by LLMs

Re: How is the Bun rewrite in Rust going?

#375

I really do not understand how software developer think anymore. Using a LLM to translate a project in a short time, is by itself incredible. Just like one-shot whatever office clone. But what makes software is not the fast creation of a "product" but that actual development of its features. Figuring out how everything needs to work together, fixing the bugs, and the o so boring UI work. I have used LLMs to create st…

> Using a LLM to translate a project in a short time, is by itself incredible. Not really. Transpilers have existed since forever. The hard part is all the edge cases. (And LLMs don't solve this problem; they probably akshually exacerbate it.)

Thank you for saying this! Every now and then I start to feel like I'm either the only sane person left or I must have gone insane and don't realize it.

LLMs amazed us and we've been trying to find a good use for them since and there's a lot things like this, replacing a transpiler with a non-deterministic machine that just guesses when it doesn't know the answer.

Shouldn't we be targeting LLMs at problems that traditional software absolutely can't handle?

Re: How is the Bun rewrite in Rust going?

#376

Earlier quoted context omitted.

> LLMs have a tendency to follow the path of least resistance That's a really strong motivation for the Rust port. It's literally impossible to take a path not leading to an unacceptable outcome because the Rust compiler fails the compile if code no longer marked "unsafe" is still actually unsafe, and the tests fail if the implementation is incorrect. The compiler actively helps to force the LLM to do things properly…

…only if you actually force the LLM not to use `unsafe` somehow! And one must remember that `unsafe` can have all sorts of non-local effects. One way to be maliciously compliant (or in the LLM's case, I guess it's more incompetence than malice) is to make a “safe” function that does an `unsafe` operation for you, and then replace every usage of that unsafe operation with your “safe” function. You can remove hundreds…

Yeah this is going out of scope now. The in-scope safe/unsafe is that which is specifically recognized by the Rust compiler (literal greppable keyword). With that and the tests weighing I'd say it's pretty difficult to be incompetent, as the correct path becomes the easy path. Even if the LLM were to somehow go the maliciously compliant route I'm thinking it'd burn so many beyond-expected tokens trying to get around both compiler and tests that it'd be caught.

Re: How is the Bun rewrite in Rust going?

#377
post #65

I am fascinated by the discourse around this Bun rewrite. I read a lot of drama and personal accusations, there are pieces like this one trying to extract clues, and it seems everyone has a deeper ideological concern behind whatever they are trying to say. For this article, it seems to be skepticism towards AI and how successful it can be at replacing programmers. Other takes, like the one from the Zig maintainer, we…

> so from my perspective I don't see why we should be skeptical that frontier LLMs guided by experienced devs can translate whole libraries like that There's a laundry list of reasons to be skeptical about LLM results in general. The biggest one is that LLMs are excellent at creating output that looks right but is nevertheless still wrong. In this particular case, there's also a specific reason: This is obviously a m…

"LLMs are excellent at creating output that looks right but is nevertheless still wrong."

"Anthropic has a long history of just lying and making shit up"

Every now and then I wonder, if LLMs were created by honest people would they be more honest themselves?

Re: How is the Bun rewrite in Rust going?

#378

I did suspect that the triumphalist pronouncements, and even the seemingly honest and forthright deep dive, were a little premature. This is a key problem with LLM exuberance: it's very tempting to trade on decades of experience in software using LLMs, because one is tired of typing and manual figuring-out, it seems to work if you're competent, and the payoff is essentially immediate. The real bill comes in the mail…

This is so real now that we have LLMs. The stuff I'm working on doesn't seem to exist in LLM training sets, but I still get tempted to try when I get tired of doing the tedious parts.

Re: How is the Bun rewrite in Rust going?

#379

Earlier quoted context omitted.

That "incidental compatibility" point is a good place to start. Unless there are serious gaps in the test suite, one can have high confidence that there's no regression from the pre-fork version in documented behavior. What kind of migration path beyond 0 regression do you think is needed? And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN? And what kind of rel…

> And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN? Where did I ever claim this? I said they don't even have the Zig build script in their repo anymore - they're clearly not intending to make any more changes to it, even if the code is still lying there next to the Rust code. > If the userbase is as miniscule as you imagine then your criticisms are essentiall…

> I said they don't even have the Zig build script in their repo anymore

And what does that matter if the ability for others to build the project isn't affected?

> they're observations

So... what do you want? It's all very pointless to even address.

Re: How is the Bun rewrite in Rust going?

#380
post #341

Earlier quoted context omitted.

I don't see how Claude code being a widely used product is relevant to the person who orchestrated the Rust rewrite of bun saying that the orchestration of the Rust rewrite of bun went well. Wc eend is a widely used product as well, if that helps. Ah, for context, which I suspect you may be unaware of, Jarred (the person who said the rewrite to rust went well) is the creator of bun, and the guy behind the rewrite.

I think the chain of reasoning is not hard to follow: 1. Assume the Rust rewrite of Bun went badly 2. Then something must be grievously wrong with a released bun runtime based on that code 3. Claude Code uses the released bun runtime based on that code 4. From #2 and #3, something must be grievously wrong with Claude Code 5. If something were grievously wrong with Claude Code, users would reduce use of Claude Code an…

Ok, thanks for explaining! Doesn't really explain how the wc eend expression _doesn't_ apply here (which would be hard to do, because it _does_ apply, since this is someone praising their own work, and it doesn't get more straightforwardly applicable than that), but I do really appreciate the effort.

I always thought it was common sense and just basic critical thinking to take people paid by Anthropic praising products of Anthropic with a grain of salt (and let's be clear, that's what this is), but apparently it's not.

Post reply on HN