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

241–250 of 560 posts

Re: Rewriting Bun in Rust

#241

Post by lionkor »

josephg wrote: post #204
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++.

It depends just how fast you need it. C++ is much easier to get to zero abstraction code.

In Rust you are constantly fighting the stdlib and other libraries, and you have to litter your hot code with unsafe blocks to get it to stop adding a branch to nearly every object access, be it for bounds checks or over/underflow checks.

C++ does a much better job at giving you a zero abstraction API, and you can always drop down to raw pointers if you want, without(!!!!) unsafe blocks and weird tricks. Of course it's unsafe in C++ but the friction to writing a branchless hot loop is muuuuch smaller.

When profiling and optimizing Rust code, I very often find myself poring over the generated code, making small changes, reading api docs, and trying again, much more than in C++. Lots of unsafe Rust APIs are not even nearly good enough, even with most checks turned off you will find branches that just branch to panic!(), which is, you guessed it, still more code and a branch than the code would suggest.

I get why people think that most systems languages are the same "speed", but they really are not if you are hitting limits of the hardware in your hot loops.

Re: Rewriting Bun in Rust

#242

Post by dgan »

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.

You and the parent are arguing over different, orthogonal things. I believe the parent argues over "efficiency"(=being able to achieve a goal for given amount of ressources) while you are replying over "efficacy" (=being able to achieve a goal). Both could be called 'maintainability' and nobody explicitely tells what definition they use, so all the long pointless discussions could be avoided if people agreed on terms

Re: Rewriting Bun in Rust

#243

Post by whytevuhuni »

rq1 wrote: post #19
Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

From a PL Theory perspective, Zig is vibe-coded. Not sure why people use it.

Pretty much everything except Haskell and the like can be considered as such.

That's because closely following PL theory isn't always the right goal for a language. Ergonomics and pragmatism are far more important.

Re: Rewriting Bun in Rust

#244

Post by lionkor »

frollogaston wrote: post #85
Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

I pay attention when someone makes a hard decision based on a hard-learned lesson. It's like, most who choose to use an ORM just heard of it or want to avoid learning SQL, everyone who removes an ORM learned firsthand horrors.

The result of this will be that you end up at the highest level of abstraction.

Let me save you time and tell you that C# and it's ecosystem is where you'll be happy.

Re: Rewriting Bun in Rust

#245

Post by [deleted] »

jatins wrote: post #238

Extremely thorough and well written. I was hoping it’d end in a “so how much did this cost?” so that others team looking at similar migrations have an estimate on what they can expect

[deleted]

Re: Rewriting Bun in Rust

#247

Post by lionkor »

> C++ instead of Zig would be a reasonable choice for Bun. We would get constructors & destructors. We could delete lots of extern "C" wrapper code.

> But, we would still be reliant on style guides enforced through code review, and even with ASAN, memory corruption and memory leaks would still happen.

Tell me you didn't even look at C++ without telling me you didn't even look at C++. I don't understand this at all, what's missing? There's clang-format, clang-tidy, cppcheck and so many others, what is missing exactly? Memory safety? Then why bring up C++ and style guides(?) at all?

Re: Rewriting Bun in Rust

#248

Post by sisve »

jamesfinlayson wrote: post #192
atrevbot wrote: post #157

Earlier quoted context omitted.

As someone who has almost no familiarity with game engines, it seems the success of this port was largely possible due to a comprehensive test suite written in a runtime agnostic way. What might be the equivalent test suite implementation required to successfully port a game engine to another language?

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 important to have close to 100% unit test in the core part. Saved me a lot.

Re: Rewriting Bun in Rust

#249

Post by KronisLV »

zamalek wrote: post #138
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…

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

> 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.

Stride should mostly fit the bill: https://github.com/stride3d/stride

Their homepage: https://www.stride3d.net/

Even the physics engine they use is in C#: https://github.com/bepu/bepuphysics2

Not a very popular game engine (never got the attention that the likes of Godot did), but it's nice to work with! It’s up there with Stride in regards to the “indie” game engines I like, maybe alongside jMonkeyEngine (since you typically don’t see that many Java game engines either).

Re: Rewriting Bun in Rust

#250

Post by aizk »

frollogaston wrote: post #85
Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

I pay attention when someone makes a hard decision based on a hard-learned lesson. It's like, most who choose to use an ORM just heard of it or want to avoid learning SQL, everyone who removes an ORM learned firsthand horrors.

Funny you mention ORMs, I'm building a project with bun, and just using raw bun sqlite until I feel the app gets too complicated and I need it. AIs are really damn good at SQL, I can just trust them with it, and it keeps the project much lighter. A few years ago this would just sound stupid, but here we are.
Post reply on HN