Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting Bun in Rust

bun.com

Post reply on HN
Print view View original

201–210 of 560 posts

Re: Rewriting Bun in Rust

#201

Post by gmadsen »

rvrb wrote: post #165
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…

that you understand and think dropping down to C++ is what you need to do when you "need the best performance" is quite enough of a tell to invalidate the rest of your opinion here. if you "need the best performance", you need to ditch OOP and RAII, and you're probably reaching for C. Zig wants to be the better choice there. that's a perfectly reasonable niche for a language to exist in. if you read the article caref…

It is widely accepted that you can get better performance with c++ far easier than C. Outside of custom rolling assembly , a large aspect of performance tuning is compile time optimization, which is extremely non trivial in C, while being supported in language with C++. All the things people associate with C performance can be done in C++, the converse is not true

Re: Rewriting Bun in Rust

#202

Post by duhhhhh1212 »

simonw wrote: post #180
bhaak wrote: post #143

Earlier quoted context omitted.

You don't need top engineers to port a program from one language to the other. Outsource it to India. Of course, then you can also ask, could it have been done with a cheaper model. Probably yes. But then you wouldn't get free marketing.

Have you seen the "rewrite by outsourcing to India" thing work?

What a weird thing to say. The phrase “outsourcing to India” being used as shorthand for “you don’t need top engineers.” The nationality stereotypes are mean and degrading.

Re: Rewriting Bun in Rust

#203

Post by PierceJoy »

smasher164 wrote: post #198

It's still shocking to me that the approach taken wasn't to have Claude write a tool that translates Zig to Rust. I imagine it would've been cheaper, deterministic, and each iteration would produce a better tool.

This seems like a much much harder problem than having a model translate between the two languages. I think people in general are way overvaluing determinism. In most cases, it doesn’t matter if the output from two runs is different as long as it accomplishes the desired goal.

Re: Rewriting Bun in Rust

#204

Post by josephg »

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…

> I can understand when you need the absolute best performance and you decide to drop to down to C++

Rust is just as fast as C++.

Re: Rewriting Bun in Rust

#205

Post by solid_fuel »

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…

Ehh, I think this take needs a grain of salt.

There's a few significant facts here:

- They had an existing functional Zig implementation

- They had an existing test suite for the Zip implementation

- They had a separate JavaScript compliance test suite with ~ 1 million tests

- The person overseeing the rewrite was responsible for a huge portion of the existing codebase and was very familiar with the existing architecture and problems

I don't think that middle management at most companies is going to be starting from that same point when it comes to building or updating something. Generally, I don't think there are many projects out there that have such robust existing tests and specifications.

In this case, the engineering behind the tests and specifications need to also be considered part of the process, since without those you wouldn't be able to build a control loop in the same way.

Also I'm pretty sure Walmart directly hires software engineers and doesn't just outsource everything - https://careers.walmart.com/us/en/results?searchQuery=softwa...

Re: Rewriting Bun in Rust

#206

Post by metaltyphoon »

reinitctxoffset wrote: post #122
YuechenLi wrote: post #29

>Combined with the Rust rewrite, ICU changes, and identical code folding, Bun's binary size shrinks by ~20% on Linux & Windows. People who are surprised by this probably has not seen what Zig code actually looks like. Zig's explicitness and lack of abstraction have a real cost that it is basically one of the most verbose programming languages I've ever seen, it's somehow even more verbose than Go. Basic features of m…

The twenty percent quoted is referring to the size of the compiled artifact (one assumes ELF or Mach-O). Whether or not a language is verbose or obscure is very much about your coordinate system. Not unlike safety. I think C is a reasonable zero for both things. Zig is more succinct and safer than C while still being comparably ergonomic. Rust is (mostly) safer and more succinct than Zig while being dramatically less…

> Rust is (mostly) safer and more succinct than Zig while being dramatically less ergonomic

This is just your opinion.

Re: Rewriting Bun in Rust

#207

Post by xeromal »

malisper wrote: post #130
simonw wrote: post #93

Earlier quoted context omitted.

I don't think it's care to categorize this as "a naive rewrite away from [Zig]" - Jarred has been immersed in this project for five years, got to benefit from everything he learned along the way and spent $165,000 of tokens on the most advanced coding LLM anyone has access to. I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.

I can confirm a naive rewrite won't make things faster. I've been working on rewriting Postgres in Rust. I rewrote things function by function similar to how Jarred did. Even though the new Rust code mapped closely with the previous C code, it was 8x slower. This was due to myriad of reasons. For example naively converting a C union into a Rust enum can be slower because Rust stores a tag with the enum, while C union…

Would love to follow your journey!

Re: Rewriting Bun in Rust

#208

Post by shimman »

PierceJoy wrote: post #203
smasher164 wrote: post #198

It's still shocking to me that the approach taken wasn't to have Claude write a tool that translates Zig to Rust. I imagine it would've been cheaper, deterministic, and each iteration would produce a better tool.

This seems like a much much harder problem than having a model translate between the two languages. I think people in general are way overvaluing determinism. In most cases, it doesn’t matter if the output from two runs is different as long as it accomplishes the desired goal.

Never thought of cross language code mods to be a thing but surely there are libraries out there that deal with the interop of different ASTs across languages? Seems like an interesting area of research.

Re: Rewriting Bun in Rust

#210

Post by koe123 »

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…

I think this problem is especially perfect for an LLM though. Its effectively translating with a great test harness.

As for your other arguments, I’m not certain we won’t just Jevon's Paradox into more work.

Post reply on HN