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.
Rewriting Bun in Rust
291–300 of 560 posts
Re: Rewriting Bun in Rust
#292Without 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%.
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
#293Earlier 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…
> 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
#294Earlier 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.
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
#295Article 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…
Re: Rewriting Bun in Rust
#296Earlier 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…
Re: Rewriting Bun in Rust
#297Earlier 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…
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
#298I 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…
Re: Rewriting Bun in Rust
#299What does it say that it took 2 months to write the blog post? (or at least have it published)
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.
Re: Rewriting Bun in Rust
#300Earlier 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…