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

131–140 of 560 posts

Re: Rewriting Bun in Rust

#131

Post by jameskraus »

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…

It's funny, I see the opposite and I would only trust a senior engineer with conducting such a wide-reaching change. I would be more likely to hire a senior engineer who might now be able to effect such change.

Re: Rewriting Bun in Rust

#133

Post by saghm »

lifthrasiir wrote: post #68
saghm wrote: post #65

Earlier quoted context omitted.

I thought Zig was supposed to be a C replacement (as in, it doesn't actually provide full safety in the way that Rust or a GC language would)?

Oh, yeah that might be confusing. I meant "you can say the same thing for GC language if that's true, which isn't necessarily true, so that must be false". More precisely speaking: GC languages are said to delay memory problems far beyond the horizon, which is often unreachable throughout the project's history. Zig can be a similar case.

Ah, I understand now. That said, I still think there's a pretty strong argument that this is a lot worse for Zig than a GC language, because they also give you safety for that overhead (and potentially ergonomics). When a language is trying to operate in the same niche as C with what seems to be an overt attempt to be less cumbersome than Rust even if it makes it less safe, it's a bit concerning to see that even without the safety it seems to have more overhead rather than less. Put another way: it sounds like it might as well just add a GC if it's not going to be competitive on performance.

Re: Rewriting Bun in Rust

#134

Post by cozzyd »

daishi55 wrote: post #117
fragmede wrote: post #112

Earlier quoted context omitted.

Claude code is buggy and they don't appear to be maintaining it just fine.

I use it all day every day and haven’t noticed any bugs. And the fact is that they are maintaining it and it is one of the most successful software products of all time and is earning them mountains of cash. By any metric it is a successful product. So obviously whatever they are doing is working.

Powertop tells me claude-cli creates an inordinate amount of wakeups, halving my laptops battery life if I leave it open. For a tui that should be doing nothing when I'm not interacting with it...

Re: Rewriting Bun in Rust

#135

Post by leecommamichael »

gpm wrote: post #116
leecommamichael wrote: post #113

Earlier quoted context omitted.

> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any add…

The comment you're replying to wasn't arguing rust > GCed languages (e.g. C# or whatever game dev language you are thinking of). It was arguing rust > non-GC non-safe languages (e.g. zig).

I see that now, thanks. There's a lot to say here, especially with other approaches to memory management. My overall goal was to give them some context that wasn't their own.

Re: Rewriting Bun in Rust

#136

Post by galleywest200 »

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…

If you already employed the engineers the extra cost would have been $0.

Re: Rewriting Bun in Rust

#137

Post by kibwen »

leecommamichael wrote: post #113
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…

> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any add…

> The best way to speed it up appears to be organizing a codebase in many crates.

A "crate" in Rust is the unit of compilation. In C, a file is the unit of compilation. Rust just lets you have a compilation unit that's composed of more than one file (without having to resort to C-style textual inclusion). But if you want, you can certainly have one-file-per-crate, just like you would in C. And what's nice about having many crates is that crates forbid circular dependencies, which trivially enables coarse-grained parallelism in the build system. So yes, organizing a large codebase into crates is the best way to achieve parallelism, but that isn't something to be deplored (and strictly controlling circular dependencies is useful for comprehending large codebases in general).

Re: Rewriting Bun in Rust

#138

Post by zamalek »

leecommamichael wrote: post #113
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…

> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any add…

Game engines are typically in two languages, one for the engine itself and one for scripting. That even goes for Unity: in Unity, C# is a significantly more powerful than average scripting language (for lack of a better term), but the engine itself is still C++.

That's not to say that you couldn't write a commercial game engine with something like C# that stands shoulder-to-shoulder with unity and unreal, but it doesn't seem like anyone has attempted to do so. Maybe it's the decompilation fear.

Also, it would continue to make sense to use a scripting language alongside Rust.

Re: Rewriting Bun in Rust

#139

Post by suby »

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 Jarred did not write these words.

I was looking forward to this blog post too, but in retrospect I don't know why. I could have had an LLM generate a hypothetical of what this blog post might have looked like and it would have probably been able to get close.

I feel like we've replaced unique voices on the internet with the same style / author, which might be more tolerable if the breathless LLM writing style wasn't so jarring. Contrary to the amount of times "But honestly" or "genuinely" is mentioned, nothing about having your LLM speak for you feels honest or genuine.

I know it's not cool to leave responses like this, but I'm really tired of all of this at this point. The ironic thing too is that it might actually be better to have LLM written text be so distinct so that you can still pick out when a human has actually authored something. Again, this is a blog post from Anthropic about having an AI translate 500k+ lines of code in 11 days, so I guess my disappointment is my fault for expecting otherwise.

Re: Rewriting Bun in Rust

#140

Post by pier25 »

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 version to fix their apps in production.

- Zero involvement with the Bun community about such a major decision. One day it was "stop the drama I'm just playing with this" and a couple of days later "yolo merged to main".

Jarred basically keeps operating as if he was a lone hacker working on his personal project.

Post reply on HN