Live data from Hacker News

Rewriting Bun in Rust

bun.com

291–300 of 560 posts

Re: Rewriting Bun in Rust

#291
post #183

Earlier quoted context omitted.

I can confirm a naive rewrite won't make things faster. I've been working on rewriting Postgres in Rust. I rewrote things function by function similar to how Jarred did. Even though the new Rust code mapped closely with the previous C code, it was 8x slower. This was due to myriad of reasons. For example naively converting a C union into a Rust enum can be slower because Rust stores a tag with the enum, while C union…

I hope that you're going to call it PostGrust.

Then you'll have postgrest on postgrust

Re: Rewriting Bun in Rust

#292
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 hope Zig won't do a hostile reply to this blog post. But some thoughts on Zig's future where a lot of these problems could be fixed or migrated by better tooling and compiler checking.

But a lot of people have been saying this for sometime, Rust and LLM is a great match. A lot of friction of the language were smoothed out by LLM assisted programming.

Re: Rewriting Bun in Rust

#293

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's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it. > The best w…

As much as I like Rust,

> In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.

Is not true, you can't have circular out of crate dependencies. This often means you now need a third crate that's a trait crate, but then you can't implement external traits on external types, so you need bridge crates, and so on.

Rust's limitation of performance requiring lots of crates indeed has real impacts on projects beyond simple hello worlds or trivial cli apps.

Considering it to be a zero impact issue is rather reductive, even in the context of the language's design principles itself.

Rust for all it's good sides has had a lack of interest from core team and energy to drive real valuable changes beyond the nightly blockers into stable, or maybe they are working real hard and the boulders are so hard to move that we can't see any change looking outside in.

Is it justified after the gargantuan effort that was merging Async and GATs? Yes.

But acknowledging the problem doesn't help us solve it.

This is to say, Rust is an amazing labour of love project that seems rather stuck in time due to lack of investment/time/effort or all of the above, I am not sure, but it's moving slower than I would like, at solving the problems Rust developers face everyday.

And yes Rust compiler is slow (very slow is arguable, compared to modern C++ it isn't that bad, but compared to say Go without cgo, its horrid), Cargo is just bad, without proper hermetic builds and stuff, even when I setup sccache for our team and our cache hit rate remained below 20% and most of it was just C++ deps hitting the cache.

Just to be clear Zig builds are quite slow too, especially on windows where debug builds also use llvm.

TBH Zig debug builds on Linux also don't really feel that fast, C still compiles faster for me by a considerable margin.

Either way as someone doing Rust everyday for last 8+ years, 5+ in small/large teams, I have lots of complaints and I am sad, it has been over years of me complaining without nearly enough progress, they have a survey declare ambitions, and then well... things just don't move much.. not nearly as much as I would have expected.

Honestly given I have been a rust dev for over half a decade now, I should instead of commenting here probably be figuring out if I can contribute to Rust to help things along (faster?).

But most meetings and discussions happen at very EU/US centric times, and number of non US/European core contributors in Rust is also rather small(I don't know of one but I hope there are a few) so as someone not in those circles, I don't have the energy to figure out my way in, with my day job.

Tldr; Is Rust the language for the job here, likely. But the question should be why couldn't have been the language Bun was written from the very start. Why does Zig or C++ or C seem so much more productive.

Sorry for ranting about this but this felt a little relevant since you claimed people complaining, are likely people who have never worked with Rust.

Re: Rewriting Bun in Rust

#294
post #57

Earlier quoted context omitted.

> what say you now? I think that when you have a $165,000 hammer, all of your problems begin to look a lot like nails.

I would guess the cost to do this with humans would be _at least_ $1.5M in compensation alone (I'm thinking three 500k/year Bay Area engineers) so this is already an order of magnitude cheaper. Is it worth $165K? I'm less sure of that but it's honestly a moot point - this will get to 5 then 4 digits of cost pretty fast.

Bay Area salaries are well-known to be extremely inflated.

Have European engineers do it for $100k or Asian engineers do it for $50k and the math is already looking a lot sketchier.

Re: Rewriting Bun in Rust

#295
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…

Hey thanks for teaching me a word today, and to be finicky myself, the convention seems to be to use a single n it. :)

Re: Rewriting Bun in Rust

#296

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's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it. > The best w…

Why do you think it is not slow? As far as I know the only language that compiles slower is C++, and even then the compilation speeds between c++ and rust seem to be comparable. I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. That makes rust pretty slow in my book. I get that it doesn’t bother everyone, but that doesn’t change the facts.

Re: Rewriting Bun in Rust

#297

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's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it. > The best w…

It depends on what you're comparing it to. It is indeed very slow when compared to a C compiler, or a zig compiler, or even a Java compiler. C++ can be comparable, or slower, or faster, depending on the C++ features used.

Sure, maybe rustc's performance compares favorably to how tsc used to be, but that's not the benchmark most Rust developers (such as myself, for more than 10 years now) care about.

> a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.

Nonsense. That's another Cargo.toml to maintain, and another place you might need to add/remove dependencies, and you have to manage the dependency tree among your sub-crates. The ergonomic impact is absolutely not literally zero, and I'd even say it's enough to be annoying.

Re: Rewriting Bun in Rust

#298

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…

"In economics, the Jevons paradox is said to occur when technological improvements that increase the efficiency of a resource's use lead to a rise, rather than a fall, in total consumption of that resource. Greater efficiency reduces the amount of the resource needed per application, lowering its effective cost; if demand is sufficiently price elastic, this induces demand, frequently resulting in a net increase of total resource consumption."

https://en.wikipedia.org/wiki/Jevons_paradox

Re: Rewriting Bun in Rust

#299

What does it say that it took 2 months to write the blog post? (or at least have it published)

He's been teasing this blog post everywhere (in commit messages, multiple times on X, here on NH [1]) so I wonder how much of it was building hype compared with it legitimately taking two months to write.

I wonder if the delay of Fable has also been a factor and maybe they didn't want to release this blog post while they couldn't allow customers to use Fable and waste the advertising opportunity.

[1]: https://news.ycombinator.com/item?id=48133519

Re: Rewriting Bun in Rust

#300

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…

UE 5 doesn’t come with a scripting language even though there is blueprints which a node editor easy enough to be used by non dev. Studios like embark (The Finals, ARC Raiders) have been successful integrated AngelScript in UE 5 and use it in these games. UE 6 will see the appearance of Verse: the scripting language used for Fortnite (and the end of blueprint at some point). At first I was sad to see yet another language but it is worth looking at the doc to see why and how it makes a lot of sense.
Post reply on HN