[johnfn]

I don't really get the Bun thing. Bun is running Claude Code which is probably the single most actively used development app there is. You say this was a bad use of LLMs, but it's been in production for a while and I haven't heard of any evidence that Claude Code has increased a significantly larger quantity of errors, segfaults, etc, than before.

[Eufrat]

Some people, myself included, think that announcing a conversion from Rust to Zig as an experiment then jumping to putting it in the alpha train for public testing/consumption without any real explanation in the span of around 2 weeks is irresponsible and reckless.

Blogposts were promised, details were hinted, but no, it’s just full steam ahead because the AI worked so well. The converted unit tests all worked, all the synthetic tests are okay, so what are you complaining about?

At some point, it’s less about the technical questions and more about getting that pesky human buy-in.

[nine_k]

They are looking for a different human buy-in.

"Yes, the AI rewrote the code. No, we do not pretend that we've scrutinized the code, or that we understand it. It works, tests pass, so we don't care, and so shouldn't you."

The "recklessness" is offered as the new normal. Because it kinda, well, works for them.

[notpushkin]

The recklessness kinda works for everybody until some point. Go fast and break things... then cash out before investors realize, unless you manage to capture the market so you can keep breaking things because people will swallow.

[gwerbin]

What's working for them is having a huge amount of resources and very good people to design a cutting edge agent harness, RLHF the hell out of their models, and build out a tremendous amount of inference capacity. I'm sure their process for making code changes in any of their client apps is very fast, but a TUI built around a chatbot is also not a particularly complicated application. So yes it's working for them, but the vibecoding that they are selling is clearly not what they are doing in practice.

[notpushkin]

They’re not talking about the chatbot TUI. The chatbot TUI was and is in JavaScript. They’ve ported the JavaScript runtime.

[gwerbin]

Yes, and it's working for them, but it's not their core competency nor does it have much to do with the actual product that people pay them for (apart from being a source of bugs to avoid), so the fact that it's working for Anthropic doesn't necessarily imply that it's actually a good idea in general. It's working for them, with emphasis on for them. Or it's actually a demo of the future and it would work for anyone, who's to say? There's no doubt that AI (and especially Claude as industry leader) helps you carry out significantly more complicated side quests than in the past, in part by enabling that "recklessness" with surprisingly little risk. Maybe an exhaustive enough test suite is really all you need. But Anthropic is not in a position to demonstrate that as the universal future of all things, not just side quests.

[yard2010]

Not GP but the js runtime has a long tail of case edges you simply can't emulate with a single app.

[notpushkin]

It surely does. I’m also extremely worried about the way they’ve decided to go with the port.

[johncolanduoni]

What does Bun’s governance look like? Now that Anthropic bought the company are there significant external contributors that would expected to have input on a decision like this?

[peteyycz]

And why buy it when they could have just called it Run and do the Rust conversion anyways? The license prohibits it, they don’t need the team’s expertise anymore, since they’re running full AI vibecode mode. Makes no sense to me

[gpm]

Seems pretty clear that they do need the team, to direct the LLM effectively.

Also they're probably interested in the team just as an acqui-hire of good developers, and they're probably interested in the marketing value of converting the actual bun to rust via LLMs. But mostly I'd assume it was about needing the team to effectively direct the LLMs.

[sharts]

IMO it’s reckless to not pin down ones dependencies. No need to pull the latest experimental hotness

[Eufrat]

I get that and I can see an argument that they didn’t really put it as stable, but I suspect the reason it is not the stable version right now is from the massive pushback as other projects and companies started pulling support for Bun because of the loss of confidence rather than any other reason.

[burnte]

How about testing the output? Seems like the ultimate test. If the output's still good, I guess the rewrite didn't hurt.

[rgoulter]

Kindof.

The problem is: quickly fixing problems (or preventing problems) benefits from having a good understanding of what the code is doing.

If you do have a suite of automated checks that's comprehensive enough that if it passes, no one will have any problems with the result, I think I'd agree. -- I don't think we're quite there at the point where "programming" is coming up with that suite of automated checks and then just not regarding the source code of the program itself.

[layer8]

Testing can expose errors, but it can’t prove correctness.

[qsort]

I agree that the Bun rewrite is much more reasonable than knee-jerk reactions imply, however:

- I don't think Claude Code is using the Rust version yet in their official build

- Claude Code is not a particularly complicated piece of software from an engineering perspective (nor it's particularly well-engineered, at least at the moment).

So in my book "it runs Claude Code" would be pretty weak evidence that the rewrite is going to be successful (the tests they've done are much better evidence, but that's a topic for another time).

[Wowfunhappy]

> - I don't think Claude Code is using the Rust version yet in their official build

No, I'm pretty sure it is, actually, since June 17:

https://code.claude.com/docs/en/changelog#2-1-181

>> Upgraded the bundled Bun runtime to 1.4

Now, Bun 1.4 doesn't seem to officially exist on https://bun.com/blog or https://github.com/oven-sh/bun/releases, so I can't be 100% sure this is the Rust version. However, I have to do some patching of the Claude Code binary to get it to run on my OS, and version 2.1.181 coincided with some changes that make suspect it's using Rust now.

[andai]

https://news.ycombinator.com/item?id=48609168

https://grigio.org/bun-1-4-the-controversial-ai-driven-rewri...

> 13,044 unsafe blocks in the resulting Rust code (hand-written Rust projects of similar size average ~73)

Grok is this true?

I've heard the meme that AI written rust code is absurdly full and safe blocks but... that's pretty funny.

Hang on. A claim like that can be verified with a single grep! Give me a minute...

    $ rg -U "unsafe\s+\{" . | wc -l
    10551

Hey, that's progress!

[gpm]

> I've heard the meme that AI written rust code is absurdly full and safe blocks but... that's pretty funny.

If I understand what happened here correctly this isn't really a case of any such meme, but the result of the porters (heh) telling the LLM to directly convert zig code using unsafe to match the previous code "exactly".

I.e. more like using the LLM as a fancy version of c2rust [1] (which would result in just as much unsafe) than a result of LLMs reaching for escape hatches too liberally.

[1] https://github.com/immunant/c2rust

[raincole]

It's unironically a good practice when you port from an unsafe language (C/Zig) to Rust. Porting isn't refactoring. One should keep the logic mapping one-to-one as much as possible.

The high number of unsafe blocks is a good sign.

[LtdJorge]

Counting instances of "unsafe {" is pretty useless. Unsafe is needed in "safe" code. What it allows is to create a boundary where the caller is the one that uphelds the contract. If the unsafe is in an internal library, it’s much more difficult to misuse.

[baq]

This is ironically a skill issue in prompting, especially if they had Fable access - or, more likely, they just really, truly don’t care.

[Wowfunhappy]

...but isn't Zig code entirely unsafe?

I've never understood why people make fun of Rust code that has lots of unsafe blocks. Obviously, the goal is to reduce those blocks, but consider also the number of safe blocks!

[meowface]

I agree Claude Code is seemingly (currently) not very well-engineered but I think you may be moderately underestimating how complicated it is/necessarily has to be.

[hatefulheart]

What are those complications?

Last I heard Claude Code devs were trying to compare their app to a game engine or rendering system.

This was summarily ridiculed. Are you saying that writing a game engine is easier than writing Claude Code?

[meowface]

There are multiple levels to the irrelevance of your reply.

[hatefulheart]

The irony!

[meowface]

- I agree that trying to hamfist a poorly-engineered game-like rendering engine into Claude Code was not wise - hence my agreement in my initial post that "Claude Code is seemingly currently not very well-engineered".

- All of the stuff unrelated to rendering/display is the complicated stuff I was referring to. It's actually not easy to get an agentic harness (even one with, say, the simplest TUI imaginable) to work as well as Claude Code and Codex do.

- I included "necessarily has to be" to separate the two - it does not necessarily need to have a weird buggy rendering engine thing, it does necessarily need to have lots of careful agentic massaging.

- I do not understand how the implication "writing a game engine is easier than writing Claude Code" could have been drawn from my reply.

[gpm]

> it's been in production for a while

Huh... it looks to me like bun has yet to cut a release post Zig->Rust port (the latest one on github is still on a branch that says it's written in zig in the readme). I assume that nothing is using the rust version yet...

Which also cuts against the complaints about "of course it works [...] you can put this into your production environment soon!" since they don't seem to be asserting either of those things.

[Eufrat]

The real problem is they explained nothing and just caused a lot of mistrust. The lead developer at Bun working on this project does post here from time to time and I have never seen him answer any of this. I admire his enthusiasm, but this was badly handled mostly from Bun’s side which lead to a bunch of dogpiling.

When someone on another social media platform commented expressed some concern, his response was to ask him what the explicit bug he was talking about was and that he would generate a fix. That sound you hear is the woosh as the point flies by. And in general, this just feels like a consistent problem with Bun.

[johnfn]

When you hear a woosh as the point flies by, I see someone attacking a project for using AI rather than any concrete technical reason. Jared's question is to disentangle an actual Rust-related bug report from someone who likes to complain about AI.

[burnte]

I have yet to hear any evidence that the Rust rewrite was harmful. I have no emotional investment in Bun (which I'd never heard of before the rewrite), or Zig (which I also didn't know about), or Rust (which I think is neat and that's about it), so I'm about as unbiased as you can get and from what I saw the conversion was done well, and I haven't heard of massive bugs resulting from the rewrite.

[GuB-42]

It is probably fine, it is kind of a best case scenario: porting a good code base with lots of unit tests, all hand-written. Not much can go wrong here as the LLM is kept in check by the original code, the tests, and the fact that the topic (a JS engine) is well documented.

The problem is what comes next. They now have code that they don't understand, and they are likely to work on it with AI in the future, but the new features they may introduce later will not have the luxury of hand-written tests and a reference code. So, unless they undertake the massive effort needed to fully understand the Rust code and deal with all these "unsafe", quality is very likely to go down, Microslop style.

[baq]

It’s always been a fallacy to think that large organizations have code which is understood. There are people somewhere understanding small parts up until the next round of layoffs.

[esailija]

Millions were invested in this project where they fired the expensive experts (me included) and replaced with a small army of cheap devs (which was actually more expensive and less productive than just retaining even one of the experts would have been). Couple years later the inevitable happened and the whole thing was thrown into trash. Code without anyone who understands it is just a liability.

[MuffinFlavored]

> Yes, Claude Code uses Bun. In fact, Claude Code relies on it as a core dependency and ships as a self-contained Bun executable.

I... somehow did not know that.

[stymaar]

You missed the day when they had their bun build misconfigured which ended up leaking the entirety of Claude Code's codebase? (I wish I was joking)

[baq]

The best part is how little it mattered. Everyone just shrugged.

[johnfn]

Pretty sure the author of Bun stated this was not related to Bun here on HN.

[stymaar]

It was due to Anthropic's misconfiguration of Bun so you can argue it's not Bun's fault. IIRC it's the default config though, so maybe it's a little bit of Bun's fault but I didn't check that.

[nozzlegear]

> which is probably the single most actively used development app there is

Seems doubtful, I'd put money on it being something like Visual Studio or Visual Studio Code. Maybe CC could claim the (odious) title of most actively used vibe-coded development app, though.

[andai]

Wait is the new CC running on the vibe coded Bun?