Rewriting Bun in Rust • Hacker News Board

Re: Rewriting Bun in Rust

#501

Post by vlovich123 » Thu, Jul 09, 2026, 8:42 PM UTC

Rohansi wrote: post #470

vlovich123 wrote: post #450

Earlier quoted context omitted.

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…

It's not specific to game dev but Visual Studio has hot reload for C++ that you should be able to make use of. C# compile times are fast. Performance is a lot better than you probably think, especially with modern .NET (not what Unity uses).

Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger.

Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on.

C++ hot reload is not a common experience in the ecosystem.

Re: Rewriting Bun in Rust

#502

Post by IshKebab » Thu, Jul 09, 2026, 9:37 PM UTC

pjmlp wrote: post #488

IshKebab wrote: post #476

Earlier quoted context omitted.

> How beefy is that machine to achieve 2m20? Ryzen 9 3950X (16 core). I think it was top of the line 5 or 6 years ago but it only cost me about £300 second hand for the whole PC (with 128 GB RAM - before the RAMpocalypse!) Definitely not a crazy machine. > I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD Yeah, I mean early C++ was quite a lot simpler than modern C++23! Of course it's goi…

Yes, but no one needs to use C++23 to the full extent to stress test the compiler in -O3, or go crazy with compile time execution. While I could comfortably still develop C++ in a Asus 1215B netbook with 8 GB and SSD, thanks to all the native libraries I could install, and make use via pkgconfig, the same could not be said to play around with Rust on the same netbook. This matters, because not everyone can afford top…

I don't think I really agree with that. You can make do with less powerful machines in Rust too. Until this year I was using a 12 year old quad core machine that was only a bit faster than a RPi 5.

I think the biggest issue is actually disk space. C++ isn't exactly efficient with disk space but Rust is on another level. You're going to run out of disk space on that netbook it you have any more than like 2 Rust projects built.

Re: Rewriting Bun in Rust

#503

Post by solid_fuel » Thu, Jul 09, 2026, 10:17 PM UTC

karatchov wrote: post #413

solid_fuel wrote: post #205

Earlier quoted context omitted.

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 architec…

You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job ! and btw, if it can write code, it can write tests and test suite Ai has come a long way, 2 years ago, t…

No I'm not missing anything. The existing specifications and tests provide a huge validation surface to work against for this kind of migration - they're the foundational pieces of the control loop. Without those two things, this kind of rewrite would not be possible.

We have known for decades that the hard part in programming isn't programming, it's making sure you have the right target! Bad designs and bad specifications have caused more bugs and broken software than anything else, and the time taken to develop the testing and validation suites (that is - the javascript spec tests) this rewrite used must be considered part of the engineering effort.

> and btw, if it can write code, it can write tests and test suite

You must be very early in your career. Again, the hard part is not writing the test, it's knowing which tests to write.

Re: Rewriting Bun in Rust

#504

Post by pdimitar » Thu, Jul 09, 2026, 10:24 PM UTC

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…

Of all the things I expected to read today on HN, "I chose a programming language that appeals to my political leanings" was certainly not one of them.

Re: Rewriting Bun in Rust

#505

Post by andrepd » Thu, Jul 09, 2026, 10:25 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…

This comment makes no sense. For one, "you need the absolute best performance and you decide to drop to down to C++", no, C++ and Rust are virtually equivalent in that they pretty much expose the underlying machine fully; if anything Rust makes it easier to write idiomatic performant code.

For two, there are plenty of reasons to use C++ unfortunately: compatibility with existing code based and availability of developers to name two.

Re: Rewriting Bun in Rust

#506

Post by henry_bone » Thu, Jul 09, 2026, 10:49 PM UTC

pdimitar wrote: post #504

henry_bone wrote: post #148

Earlier quoted context omitted.

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…

Of all the things I expected to read today on HN, "I chose a programming language that appeals to my political leanings" was certainly not one of them.

With the use of quotes there, you've put those words in my mouth. I didn't say that.

What I am trying to express with the statement you refer to is that zig appeals to me on an aesthetic level. It suits my tastes.

I mentioned liberty because I appreciate that zig allows me to have complete control of memory allocations, and gives me quite a deal of control over the metal. I like this and I like that I don't have to appease a borrow checker. Zig's compiler and type system is strict enough to guide me to correctness, but the experience, broadly, is not so onerous that programming becomes tedious and frustrating.

These qualities, I suspect, resonate with my individualistic tendencies.

Re: Rewriting Bun in Rust

#507

Post by alwaysbeconsing » Thu, Jul 09, 2026, 10:55 PM UTC

srdjanr wrote: post #464

atonse wrote: post #170

Earlier quoted context omitted.

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 sing…

I have a few opinions on this: 1) My (and possibly other people's) last impression of this was when it was merged just based on all tests passing. In many projects, relying just on tests would definitely be reckless (not sure about coverage/quality of Bun tests). I didn't follow much what where they doing later, maybe it is indeed good enough. For example, Claude Code using it and being fine is reassuring. 2) Making…

> You can be reckless even if everything ends up being perfect in the end.

This. Something I expect any person who think they are "engineer" to understand without thinking.

Re: Rewriting Bun in Rust

#508

Post by DoesntMatter22 » Thu, Jul 09, 2026, 11:13 PM UTC

stymaar wrote: post #360

msdz wrote: post #355

Earlier quoted context omitted.

> tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal. For our small codebases, maybe. The tsc-in-Go announcement had VS Code compilation go from >120 seconds to ten .

Exactly: tsc was “slow enough to be painful” in the context of the 2.5Mloc codebase of VScode. But it's not too slow for most people. Likewise, Rust may be slow enough to be painful for some big projects that need to often rebuild from-scratch in release mode, but that niche is definitely much smaller than the size of the “rust compiles too slowly” crowd on HN. I gave Rust classes in university a few years back, and…

Small apps in college are much different than huge apps in the real world

Re: Rewriting Bun in Rust

#509

Post by jamesfinlayson » Thu, Jul 09, 2026, 11:21 PM UTC

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…

I agree - maybe some modern game engines have unit tests for stuff like their physics engine and their "standard library" code (optimised data structures, maths utilities, string utilities etc) but as others have said, testing sound and vision is hard, and something that hasn't been mentioned is all the different flags in a game engine - testing even a sensible subset of all the different sound and rendering variables would be a huge undertaking.

Re: Rewriting Bun in Rust

#510

Post by Rohansi » Fri, Jul 10, 2026, 12:21 AM UTC

vlovich123 wrote: post #501

Rohansi wrote: post #470

Earlier quoted context omitted.

It's not specific to game dev but Visual Studio has hot reload for C++ that you should be able to make use of. C# compile times are fast. Performance is a lot better than you probably think, especially with modern .NET (not what Unity uses).

Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger. Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on. C…

> only work on Windows with Visual Studio

Really shouldn't be a dealbreaker when 95% of your users will be using Windows (to play games), so your most tested platform should be Windows.

> when you started it under a debugger

Hot reload isn't a replacement for scripting IMO. It will never be as good. Even hot reload in Rust would have more limitations than an actual scripting language.