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

341–350 of 560 posts

Re: Rewriting Bun in Rust

#341

Post by hresvelgr »

grandimam wrote: post #232

The rewrite itself is amazing, but I don't think folks realise the actual conditions that made it possible. It's not as simple as a company spending ~$160K on tokens. This was done by someone who has essentially already rewritten Node once. Bun itself is a reimplementation of Node, so the author was walking in knowing exactly what the correct behavior is. And an exhaustive amount of test suite to verifiy the changes?…

The condition that made this possible is that this task is well within frontier LLM capability and he had tokens to burn. Domain knowledge is separate to language semantics.

Re: Rewriting Bun in Rust

#342

Post by egorfine »

jsnell wrote: post #167
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, no…

> Pangram is very good at distinguishing between AI-generated and human text

It's not.

Re: Rewriting Bun in Rust

#343

Post by pjmlp »

IshKebab wrote: post #304
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 rust compiler is very slow. It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast , but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games. > a garbage collector eliminates a large amount of defects (including the ones stated in the article) with…

Because contrary to Rust, C and C++ have a culture of binary libraries.

You are seldom compiling the world from scratch.

Especially in the platforms dear to game devs.

Re: Rewriting Bun in Rust

#344

Post by mike_hearn »

sisve wrote: post #248
jamesfinlayson wrote: post #192

Earlier quoted context omitted.

Gosh, I don't think any game engines have particularly good test suites at all. GoldSource and Source are the only ones that I have any real experience with and neither seems to have anything (Source may have a handful of things but nothing approaching baseline let alone comprehensive). I have no idea how game devs handle big refactors other than lots of manual testing.

> Gosh, I don't think any game engines have particularly good test suites at all. What? I do understand that a CRUD app with little to no logic do not focus on test. But any kind of engine.. i can not understand that it's not a priority? In general I'm not a big fan of unit test on simple websites, they do not give any real value compared to effort But I remember working on a complex codename. It was extremely import…

A game engine has a vast space of possible outputs, all of which will be considered good enough.

Its primary output is pixels and sound. Those are hard to test in a reasonable way. Screenshot testing is useless in a codebase where most of the changes are about making the pixels prettier.

Re: Rewriting Bun in Rust

#345

Post by vrtcn »

I am a bit suspicious about the choice of startup time as the metric to evaluate performance in Claude Code. With a rewrite from a language like Zig to Rust, my biggest performance concern would be allocation. Where a Zig app might use a fast linear or buddy allocator, a Rust app is more likely to use malloc. During startup, both versions are likely to make tons of allocations. In fact, the Zig version is likely to make larger allocations during startup to reserve memory for its custom allocators. So I would expect both versions to be roughly on par, or Zig slightly worse there. However, during normal execution, I would expect the Zig version to be potentially faster, because it has paid the cost of malloc at startup and now an allocation might be as fast as incrementing an integer. This is speculation, but I would like to see performance numbers for the rest of the app lifecycle.

Re: Rewriting Bun in Rust

#346

Post by egorfine »

To me this whole saga stands on a very thin overlapping region between "it has merit" and "I hate it". Like, the blog post clearly explains the merits and they are strong. At the same time, I absolutely hate how the author handled the whole rewrite, including throwing the whole community out the window along with all their contributions and human love.

Re: Rewriting Bun in Rust

#347

Post by egorfine »

Any chance for 1.3.15 with top bugfixes for those of us who once trusted Bun and are stuck on it in production? I have migrated almost everything out of Bun by this point but I have one single project that builds into executables with Bun and relies heavily on Bun's SQLite.

Re: Rewriting Bun in Rust

#349

Post by waysa »

I tried Bun for a weekend around Christmas 2024. I quickly hit a bug that would freeze the runtime (issue #13237) when piping a stream into a file. I found that this had been open since August 2024, scrapped the experiment and moved on. The issue is open to this day. If the GitHub comments can be trusted, this behavior even carries over to the Rust port.

Re: Rewriting Bun in Rust

#350

Post by anentropic »

vrtcn wrote: post #345

I am a bit suspicious about the choice of startup time as the metric to evaluate performance in Claude Code. With a rewrite from a language like Zig to Rust, my biggest performance concern would be allocation. Where a Zig app might use a fast linear or buddy allocator, a Rust app is more likely to use malloc. During startup, both versions are likely to make tons of allocations. In fact, the Zig version is likely to m…

Those were in the article https://bun.com/blog/bun-in-rust#2-5-faster
Post reply on HN