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

161–170 of 560 posts

Re: Rewriting Bun in Rust

#161

Post by minimaltom »

bhaak wrote: post #143
Jenk wrote: post #109

Earlier quoted context omitted.

$165k won't get you far on salaried engineers. There's every chance that 1 engineer, assuming Anthropic employs them, is on $500k or more. Assuming average of $336k in that pool of 50 engineers, then for 11 days for 50 engineers you've spent $710k[0]. Salary info: https://www.levels.fyi/companies/anthropic/salaries/software... [0]The maths I used (posting because I'm tired and prone to mistakes): $336,000 / 260 (work…

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.

I agree you probably don't need top-dollar bay-area engineers for this, but hardcore outsourcing to a LCOL probably isnt going to work either due to novelty and generally being setup to do the more rote thing (generalizing a ton here obvi). This feels like something in the middle.

Re: Rewriting Bun in Rust

#163

Post by rifty »

Super interesting!

I feel like people will make the wrong comparison with the cost to complete. $165000 should be compared to not the cost of a programmer going line by line by hand but someone designing a transpiler from zig to rust. The time to complete is impressive though, if you could spend $165000 and a year of time to find out the rewrite project worked, or instead spend that in a month, you'd probably take that month now that this proof of concept exists out there.

Re: Rewriting Bun in Rust

#164

Post by kibwen »

henry_bone wrote: post #148
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'll bite. The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it. Rust is pushed by many as the replacement to C, because of the memory safety guarantees. I'm sympathetic. I worked with Haskell for a time, so I get it. But Rust seems quite complex. There are so many language features that there's memes about it. There's also…

> There are so many language features that there's memes about it.

Like many memes, these are misleading. Rust is a solidly medium-sized language; smaller than Python, certainly, though with a perilously steeper learning curve than Python.

Re: Rewriting Bun in Rust

#165

Post by rvrb »

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 carefully, jarred is pretty clear about how their specific requirements with Bun cause friction when bridging the manual memory management of Zig with a garbage collected JS runtime. at face value, that makes quite a lot of sense to me, and it's a pretty specific scenario that is not the full on condemnation of memory unsafe languages that your comment is.

Re: Rewriting Bun in Rust

#166

Post by alexjurkiewicz »

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…

Paying customers get LTS. Are any paying customers asking for a Zig branch LTS? Or are you expecting open source maintainers to do free work for no particular reason?

Re: Rewriting Bun in Rust

#167

Post by jsnell »

suby wrote: post #139

I'm so jaded at this point. The AI translation from Bun to Rust doesn't bother me, I think it's interesting, but that this blog was so clearly written by LLM's is offputting for some reason. I think after having to interact with LLM's for much of the day, it's exhausting to read LLM speak in so many things I see online. It feels almost disrespectful to the reader. It's written from a first person perspective, but Jar…

> that this blog was so clearly written by LLM's is offputting for some reason

It doesn't read at all AI-generated to me. What section do you think is?

(Pangram is very good at distinguishing between AI-generated and human text, and assigns a very low score to the article: https://www.salahadawi.com/hacker-news-ai-detector/rewriting...)

> Contrary to the amount of times "But honestly" or "genuinely" is mentioned, nothing about having your LLM speak for you feels honest or genuine.

"Honestly" is used once in that post, in a way that's pretty much the core, self-deprecating human use for it ("It would have been possible to do X, but honestly I didn't want to"), rather than the filler word use-case.

"Genuinely" is not used at all.

> I know it's not cool to leave responses like this, but I'm really tired of all of this at this point.

I think it is cool to flag AI-generated slop and either leave a comment or upvote an existing comment about it being slop. But only if you are sure it's AI-generated. And sorry to say, you don't seem very well calibrated on this. If you can't actually tell the difference and back up your opinion but are just guessing, then it indeed isn't cool.

Re: Rewriting Bun in Rust

#168

Post by kgeist »

kvuj wrote: post #159
kgeist wrote: post #45

Earlier quoted context omitted.

>they turned it into something unreadable Did you compare the code before/after? It's a mechanical line-by-line port, and most of the code is identical to the old version, just with Rust syntax. They have an example in the blog post.

But how can it be a mechanical rewrite if the tool used isn't deterministic?

It converges to "almost deterministic" on highly predictable outputs (i.e. code) with the right sampling params (say, you only sample the most probable token without randomness/high temperature) and with self-correction loops

Re: Rewriting Bun in Rust

#169

Post by remexre »

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…

the point of c++ when you need max perf is to be able to maintain the compile-time abstractions you need w/ templates instead of macros and undocumented optimizer behavior, not oop or raii

Re: Rewriting Bun in Rust

#170

Post by atonse »

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…

LTS is more relevant if there was any kind of compatibility that was broken. They still haven’t released 1.4 even though it seems to have gone extremely well by every metric in the wild, with tons of people using Claude code with no regressions in a month. Nothing to me suggests they’re being careless here.

In fact, he had two adversarial reviewer Claude instances on every code change, every line. I don’t know a single human team that does two independent reviews of every line, except maybe the people that wrote space shuttle software.

Also they fixed the memory leak. How does it matter what language it’s written in? At the end of the day, people use it to run their typescript code among other things.

How many bun users care that’s it’s written in zig? I certainly don’t. I’ve been using bun for 2 years and I think I looked up zig once. It’s just not relevant.

Did it get more stable? Yes. Slimmer? Yes. More performant? Yes. Is there any proof that it got LESS secure? No. The code has been out for two months. By now all the nay sayers would’ve found the smoking gun. They haven’t. How much more proof would you like that this was a resounding success?

This is our new reality. The agents are so good that projects like this are in the realm of possible. That’s exciting.

Post reply on HN