Rewriting Bun in Rust • Hacker News Board

Re: Rewriting Bun in Rust

#441

Post by darkwater » Thu, Jul 09, 2026, 1:55 PM UTC

Ygg2 wrote: post #438

afry1 wrote: post #429

Earlier quoted context omitted.

Technology does not exist in a vacuum, nor does anything that is engineered. It's not this abstract stuff detached from the world. PEOPLE make stuff, people use stuff, and people are ultimately the ones who are going to pick and choose which stuff gets made, used, adapted, enhanced, and carried into the future. AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that. As…

> AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that. Not really. LLMs are a tool, and they do possess some interesting properties, but they are, in essence, a very surprising auto-complete. No, what sucks is the AI companies marketing them as if they are The Holy Grail. And people are assuming that somehow LLM -> AGI -> ASI, even though there isn't really a causal…

If you think like this - and you are most probably right IMO as well - then you should somehow share GP feelings, because LLMs are made by companies like OpenAI and Anthropic and Bun was bought by Anthropic and ported to Rust by Anthropic.

TBH in hindsight it seems that the Bun acquisition was also for the PR stunt they just did with the Rust porting.

Re: Rewriting Bun in Rust

#442

Post by low_tech_punk » Thu, Jul 09, 2026, 1:56 PM UTC

(1) The original zig code was probably heavily AI coded with lower quality, hence the bag. There is a chance that a full rewrite in zig might do as well but we will never find out.

(2) The rewrite itself is a massively successful marketing move. It shows what Claude code can do and how little it costs compared to human engineering. But the question remains whether someone else, not knowing zig, rust, and TypeScript can pull this off.

Re: Rewriting Bun in Rust

#443

Post by ubercore » Thu, Jul 09, 2026, 1:57 PM UTC

Georgelemental wrote: post #37

dfabulich wrote: post #27

This blog post further undermines my trust in Jarred. He makes it sound like Claude did a fantastic Rust rewrite, and "the work continues." But when the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of `unsafe`, no Miri tests at all, and, sure enough, it exposed UB in safe Rust. https://github.com/oven-sh/bun/issues/30719 Observers could see this coming from a mile aw…

Pre-release code had bugs that were fixed before the release? Why is that a problem? That's the point of having a testing and release process

It's partly a problem because the narrative is still "rewrote Bun in Rust in 11 days". And they didn't do that, if you consider quality of code. And now people look and see "look what you can do with an LLM in 11 days"

Re: Rewriting Bun in Rust

#444

Post by lunar_mycroft » Thu, Jul 09, 2026, 1:57 PM UTC

padjo wrote: post #421

It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this…

There were/are absolutely plenty of real problems with the resulting code pointed out. Running Miri trivially found soundness issues, `SAFETY` comments that demonstrate that the model in question fundamentally doesn't understand/simulate understanding how unsafe rust works [0], etc.

[0] https://github.com/oven-sh/bun/blob/fc865b398e51de8a95ddde4b...

Re: Rewriting Bun in Rust

#445

Post by josephg » Thu, Jul 09, 2026, 1:59 PM UTC

hkalbasi wrote: post #364

lionkor wrote: post #241

Earlier quoted context omitted.

It depends just how fast you need it. C++ is much easier to get to zero abstraction code. In Rust you are constantly fighting the stdlib and other libraries, and you have to litter your hot code with unsafe blocks to get it to stop adding a branch to nearly every object access, be it for bounds checks or over/underflow checks. C++ does a much better job at giving you a zero abstraction API, and you can always drop do…

> over/underflow checks. Integer overflows are not checked in release builds by default, since they are not related to memory safety. On the other hand, rust emits noalias everywhere, which helps in autovectorization.

Yep. And array bounds checks have a miniscule performance impact at runtime because they're so friendly to branch prediction.

Re: Rewriting Bun in Rust

#446

Post by ryukoposting » Thu, Jul 09, 2026, 2:01 PM UTC

didibus wrote: post #80

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…

tl;dr: my job requires me to do things where Rust's memory model can't save me.

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

Re: Rewriting Bun in Rust

#447

Post by vincnetas » Thu, Jul 09, 2026, 2:03 PM UTC

pier25 wrote: post #140

Personally I don't care that they used AI to rewrite Bun to Rust. Even if 1.4 is not good enough it will probably get better over time. What has pushed me back to Node is seeing how amateurish the transition has been handled. - No LTS support for the Zig version regarding CVEs etc. - Huge bugs like the 3MB memory leak mentioned in the blog post abandoned in the Zig version to basically force people into the Rust vers…

this reminded me of WoW classics: Leeroy Jenkins

yolo!!!

Re: Rewriting Bun in Rust

#448

Post by OGWhales » Thu, Jul 09, 2026, 2:05 PM UTC

sashank_1509 wrote: post #125

I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow. Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify…

This project is very well suited for AI. It's not clear to me if AI is nearly as good or cheap when building things that are new, where it doesn't have an existing target to match and doesn't have an existing test suite to bounce off of and has the benefit of being lead by an actual human with a very intimate understanding of the codebase.

Re: Rewriting Bun in Rust

#449

Post by QuadmasterXLII » Thu, Jul 09, 2026, 2:05 PM UTC

StriverGuy wrote: post #416

QuadmasterXLII wrote: post #412

Putting on my machine learning PhD student hat, the way to do this was to leave 10% of the tests out as a ‘test’ set and then once the port was done, bring them back in and find out how good the port is. The port may genuinely be good but because they spent 100k of compute hill climbing the whole test suite, “the test suite passes” now provides far less evidence that the port is good. Its weird that at Anthropic, a v…

Huh? This approach makes sense for non-deterministic problems. Not engineering problems that have deterministic end results.

I’d want to estimate P(a random test passes) where the existing suite of tests is taken to be sampled from a distribution.

Re: Rewriting Bun in Rust

#450

Post by vlovich123 » Thu, Jul 09, 2026, 2:08 PM UTC

Rohansi wrote: post #240

vlovich123 wrote: post #220

Earlier quoted context omitted.

For what it’s worth game devs often use C# or C++ engines which have even worse issues. Rust also has the early beginnings of hot reload which bevy adopted if I recall correctly [1]. I still think a higher level language is good for “business” logic to orchestrate how efficient low-level pieces connect, but Rust is holding its own even against those use cases IMHO. [1] https://docs.rs/hot-lib-reloader/latest/hot_lib_…

> For what it’s worth game devs often use C# or C++ engines which have even worse issues. Such as? You can't be referring to hot reload alone because you can already do that in both C++ and C#.

Well for c++ memory safety and sharp abstractions and even worse compile times than Rust. I’m not aware of hot reload really being done in c++ at any scale but I’m not a game dev so I’m open to learning.

C# AFAIK holds a minor place in gamedev and also has slow compile times maybe? I assume it has better support for hot reload times. But generally the performance profile isn’t there for the most demanding games even if the DX is.