Live data from Hacker News

My thoughts on the Bun Rust rewrite

andrewkelley.me

581–590 of 757 posts

Re: My thoughts on the Bun Rust rewrite

#581
post #538

Earlier quoted context omitted.

> I've dealt with many shitty code bases and the only way that worked for removing bugs was automation. It didn't matter how many bodies you threw at the problem. Can't say my experience matches yours. Types do seem to structurally reduce some varieties of bugs, but ultimately the only reliable way I've seen to close the gap is hire disciplined people who care about, and thoughtfully consider, what they build. E.g.,…

> but ultimately the only reliable way I've seen to close the gap is hire disciplined people who care about, and thoughtfully consider, what they build. You were able to turn around a codebase that was growing its bug count exponentially by changing an entire company's hiring practices? I really don't believe in the "just don't be stupid" or "don't hire stupid people" approach to things. If it works, it only works at…

In short, yes.

Re: My thoughts on the Bun Rust rewrite

#582
post #512

Earlier quoted context omitted.

Yeah, and the kind of contributors you attract with this kind of writing are just assholes

I'm not sure if you're intentionally branding an entire language community that way or not but it might be less broadly offensive to tone that down. You could make a similar point by saying something like "I don't like the message he's sending so I won't participate" without labeling anyone who associates with him an "asshole".

> You could make a similar point by saying something like "I don't like the message he's sending so I won't participate"

Sooo.... "be more professional in your writing"?

Why does this person owe you "professional writing" on their personal comment?

Re: My thoughts on the Bun Rust rewrite

#583
post #93

> You can imagine how we might want to put some social distance between ourselves and a project whose irresponsible software engineering practices invite the exact kind of criticism that people are eager to level. The other (very salient) points notwithstanding, I'm afraid this quote shows that Zig hasn't learned a lesson that other languages of its generation (and older) have: if a project's memory safety depends on…

I mean, case in point. (One of?) Zig's largest adopted projects who was donating $60,000 a year made by a contributor that worked directly with Andrew... Was not "stinky" engineering.

If Bun can't get it right starting in 2026 with all of Zig's tooling and someone who worked on the language, what hope does my random team have?

Especially when we could, instead, use Rust. With a larger community to boot.

Re: My thoughts on the Bun Rust rewrite

#584

Earlier quoted context omitted.

Memory safety problems are still possible in the new Rust Bun: 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.

Yes - I think the proof of the pudding will be whether they put in the effort to eliminate these unsafe blocks. The conversion to Rust is the starting point that makes this possible, but it's definitely not "done" at this point.

If the majority of those are at an FFI boundary to a language without lifetime analysis, I don't really see how they could be fixed without rewriting all that downstream software?

Re: My thoughts on the Bun Rust rewrite

#585
post #561
post #402

Yikes, the majority of this blog post is saying basically "skill issue" and "Jarred bad engineer", but I think that hurts Zig far more than Andrew realises. If Bun, a disaster of engineering apparently, simply just switches to Rust and all of their issues magically disappear... then the Rust Vs Zig war is over before it started right?

Yet to be determined. The rust port isn't fully released yet. That might be why they hurried and declared victory now instead of waiting until later?

The rust port is the canary build now, being actively deployed to production in Claude Code and Prisma Compute (Beta).

Re: My thoughts on the Bun Rust rewrite

#586
post #538

Earlier quoted context omitted.

> but ultimately the only reliable way I've seen to close the gap is hire disciplined people who care about, and thoughtfully consider, what they build. You were able to turn around a codebase that was growing its bug count exponentially by changing an entire company's hiring practices? I really don't believe in the "just don't be stupid" or "don't hire stupid people" approach to things. If it works, it only works at…

In short, yes.

I'm curious and would love to hear more. In long?

Re: My thoughts on the Bun Rust rewrite

#587

Did everyone forget how when the news first broke, Jared told everyone to calm down; it wasn’t a big deal? That was very deceitful to me. Jared seems like the typical SV tech bro who deserves this type of personal disrespect, but of course 90% of people on this site would love to him and wouldn’t understand.

Jarred, reasonably and publicly, did not expect a 1.2 million line rewrite to finish, fix a hundred bugs, and have no noticeable regressions in 11 days of experimenting.

Re: My thoughts on the Bun Rust rewrite

#588

Earlier quoted context omitted.

>Posting it in this sprawling, mean form was dumb. Thank you for putting my thoughts in words I can never string together so well. I too would just stash the letter in my ZFS dropbox and never let it see the light of day again. The letter reads like a husband who was just served a divorce notice from his wife. The man is angry, and wants everyone to know that he is not angry, and he is very much not bothered by the w…

And I see AI maximalists circling the wagon.

I'm as anti-AI as they come and I mostly think everyone involved in this is making their respective projects and ecosystems look worse for it here.

Andrew was still way out of line in making many of the points included in this post, you don't have to be pro-AI to feel that way.

Re: My thoughts on the Bun Rust rewrite

#589
post #582
post #512

Earlier quoted context omitted.

I'm not sure if you're intentionally branding an entire language community that way or not but it might be less broadly offensive to tone that down. You could make a similar point by saying something like "I don't like the message he's sending so I won't participate" without labeling anyone who associates with him an "asshole".

> You could make a similar point by saying something like "I don't like the message he's sending so I won't participate" Sooo.... "be more professional in your writing"? Why does this person owe you "professional writing" on their personal comment?

> Sooo.... "be more professional in your writing"?

No, just more precise. It seems absurd to brand an entire community as "assholes" based on some disagreement with a blog post by one member. I suspect great GP didn't mean it that way, but it would help to have some clarification.

Re: My thoughts on the Bun Rust rewrite

#590
post #492
post #472

Earlier quoted context omitted.

For me, using Fuzzilli for testing a Zig code is not fuzzing, it's integration testing. If you're running code externally (e.g. wrapping binary) you cannot guarantee that side effect isn't caused by IO. I consider fuzzing a low level activity with many external variables removed. Depending on where you are and how you communicate semantics matter more or less. It's very similar to compiler/transpiler. E.g. TypeScript…

My point is that Kelley did not argue that what Bun does isn't really fuzzing. He wrote that the post's claim is a fabrication. But that claim is really specific, and to evaluate whether it is true it doesn't matter what Kelley's unstated definition of fuzzing is. So an argument about definitions doesn't seem super valuable here.

The Fuzzilli PR was merged on Nov 20. The acquisition was announced on Dec 3. A big holiday was in the middle.

The teams no longer interacted after the acquisition, and in prior interactions the Bun team would've been correct in saying they weren't fuzzing.

So Jarred isn't wrong, and Andrew also isn't wrong.

Post reply on HN