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

251–260 of 560 posts

Re: Rewriting Bun in Rust

#251

Post by aizk »

lifthrasiir wrote: post #64
silver_silver wrote: post #56

Earlier quoted context omitted.

People say a lot of things, especially when they have a vested interest in a positive outcome. Bun has been fully vibe coded into another language. There’s no way in hell it’s maintainable. Go read any analysis of the Claude Code leak for proof.

Claude Code is entirely vibe-coded for a long time. Bun isn't. You go read and compare the actual Bun code; it reads reasonably well [1]. [1] For example, as a random sample, https://github.com/oven-sh/bun/blob/bun-v1.3.14/src/css/medi... -> https://github.com/oven-sh/bun/blob/4924862cffbf671792d47c92...

That vibe coded app is generating billions. Does the word "vibe coded" mean anything anymore?

Re: Rewriting Bun in Rust

#252

Post by whytevuhuni »

steveklabnik wrote: post #187
sitzkrieg wrote: post #181

Earlier quoted context omitted.

rust is still a non starter in some niche embedded applications (way too big). i still write c and assembly constantly.

> way too big https://github.com/tormol/tiny-rust-executable This produces a 137 byte binary. Obviously AMD64 isn't used in embedded, but I've seen ARM ones that are in the ~256 range. It's all in how you use it. Of course, if you don't care about binary sizes, they can get large, but that's very different than actually paying attention to what you're doing.

I tried to use Rust for a tiny microcontroller (GD32VF103, 128KB flash).

First of all, I was amazed by how much I could do with Rust (safe Rust, even), and how well it was interfacing with my handwritten RISC-V assembly. I will definitely use Rust again for the next such project.

But, every time my functions would get over a certain size, suddenly some optimizations stopped working, and Rust was trying to put the whole panic/fmt machinery into the thing, going above my linker's flash size limit. It was insanely frustrating, since there was no rhyme or reason to it. Simply adding another branch to a match made it do that. Or another if statement that was exactly the same as the 4 before it.

The 137 binary thing does not scale.

Re: Rewriting Bun in Rust

#253

Post by kubb »

lionkor wrote: post #247

> 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, w…

Not replying directly to OP, just to people who never coded in C++.

Clang-format doesn’t save you from all C++ footguns, e.g. using exceptions, macros or templates in the wrong way where „wrong“ is defined by a fuzzy set of rules that requires a lot of experience and vigilance to enforce.

Re: Rewriting Bun in Rust

#254

Post by jordand »

The thing you have to remember with that $165k spend on tokens is that token prices are going to keep rising, and models may not get much better. I wouldn't be surprised if doing this same migration in 6 months time would end up costing $250k+

Re: Rewriting Bun in Rust

#256

Post by hdjrudni »

zamalek wrote: post #186
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?

One option would be to have an input replay alongside captured outputs (audio visual), at some fixed framerate. Capturing intermediates (scene graph etc.) would probably also be valuable, as that could help nail down why something is failing. Or you could do it [as I recall the project being called] the scientist way. You still have the old code, so you could replay inputs against each and compare. Probably more real…

Box3D just showcased some stuff including deterministic replays. If you wanted to port that, you could probably import the replay and make sure it plays back the same way in your new language. I think it captures the inputs and forces applied, not the pixels.

I suppose rendering is a component of a game engine too though, not just physics. I don't know how to do that reliably. Even if you captured pixels, it'd be annoying. If you've ever tried doing screenshot based diffing on web you will know that slight changes in aliasing in Chrome bugger everything up. Things that should be equivalent randomly aren't but not in a way that any human would care.

Re: Rewriting Bun in Rust

#257

Post by capiki »

jordand wrote: post #254

The thing you have to remember with that $165k spend on tokens is that token prices are going to keep rising, and models may not get much better. I wouldn't be surprised if doing this same migration in 6 months time would end up costing $250k+

do you think price per task completed will rise as well?

Re: Rewriting Bun in Rust

#258

Post by imtringued »

lionkor wrote: post #241
josephg wrote: post #204

Earlier quoted context omitted.

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

How is not having to mark your unsafe code as unsafe a good thing?

You couldn't have come up with something more incomprehensible.

If 99% of your code doesn't use unsafe, why contaminate 100% of your code base with footguns?

Re: Rewriting Bun in Rust

#259

Post by hdjrudni »

ozgrakkurt wrote: post #239
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 is highly debatable if a 200k cost engineer that is suitable for the job wouldn’t bring in more value. Also it is debatable they got any value at all from this. Anyone who wrote unsafe rust and also wrote zig would know that unsafe rust is much much more unsafe in comparison

It's only 4% unsafe and most of it is single-line pointers that came from C++

> At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library.

I don't know much about Rust but I imagine this is safer than 100% 'unsafe' code in Zig or C++.

Re: Rewriting Bun in Rust

#260

Post by marcianx »

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

It's right there under "Stats":

> 11 days (May 3 → merged May 14) · 6,778 commits

> Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing. By hand, I think this would've taken 3 engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would've done that. The realistic alternative was to do nothing and keep fixing the bugs at the top of this post forever.

Post reply on HN