Live data from Hacker News

My thoughts on the Bun Rust rewrite

andrewkelley.me

221–230 of 757 posts

Re: My thoughts on the Bun Rust rewrite

#221

Earlier quoted context omitted.

4) It's led by an emotionally unintelligent individual who will personally attack you for choosing alternative products.

Like Linus?

Linus attacked bad software, Andrew attacks the Thiel Fellowship, VC Foundings, and AI. There's little or no Linus there, pointing fingers at, and even when he does, he points at code he neither uses nor maintains. Linus don't give a shit about other people projects and businesses.

Re: My thoughts on the Bun Rust rewrite

#222

There are astute comments about the post's tone elsewhere in this thread[0] But this killed my hopes for Zig. The drama is fun, and Andrew is maybe even admirable in his earnest, but this just isn't the kind of professionalism needed for a serious project. I know that's boring and uninspired, but that's what I want my tech stack and it's management to be. Also, maybe Jarred was a net negative, but bun was also a real…

> this just isn't the kind of professionalism needed for a serious project

I don't immediately see how much the seriousness of the project is related to the language the author chose in their personal blog post. It's similar to saying that Linux could not have become a serious project because of the way Linus communicated in his emails.

Re: My thoughts on the Bun Rust rewrite

#223
post #99

Earlier quoted context omitted.

Even if you “rely on countless unsafe blocks”, unsafe is additive, it gives access to additional APIs which are not checked. It does not disable affine types, the borrow checker, or send/sync traits. Unless the entire codebase is unsafe (e.g. fresh out of c2rust) it’s very hard to not have more guarantees. And because unsafe is generally highly local or localizable reasoning (conventionally backed by safety justifica…

For 99.99% of cases, you're reading and writing this under an operating system whose kernel is written in a language without send/sync, and inside a browser that also largely written in languages without send/sync, because those systems are fundamentally well designed. So instead of fixing the bugs and rethinking the architecture, the author of Bun decided to transpile almost the entire codebase from Zig to Rust with…

Those systems you're alluding to received ungodly amounts of work and resources, vastly more than most projects can ever hope for, and yet they're still full of holes and security exploits. You're unwittingly making a great argument against using C, C++ – or Zig.

Re: My thoughts on the Bun Rust rewrite

#224

Earlier quoted context omitted.

It's kind of strange to not engage with any of the points made in the article. Unlike you, I don't think the post makes them look childish at all. I think it raises a lot of valid points and makes me want to use Zig more.

Do you have bias? I'm not saying I don't have some hidden bias but I have no skin in the game. I don't use Bun or Zig or plan to. My reflection comes after reading Jarred's post yesterday, which I found interesting, and then Andrew's today. I just pasted this article into an LLM to understand the tone and the summary is: > The overall tone is deeply personal, cathartic, biting, and polemical, with flashes of humor an…

Did you have a hard time picking that up from the article itself? I don’t see the point of asking an LLM to tell you what to feel about the article.

Re: My thoughts on the Bun Rust rewrite

#225
Thank you Andrew for sharing your side of the story. We can see that the relationship with Bun and Jarred was far from easy. You say it with your own words and even if it sounds bitter I like it much more than some bland AI assisted content.

Re: My thoughts on the Bun Rust rewrite

#226
post #104

Earlier quoted context omitted.

I’m reminded of the hierarchy of controls in machine safety. If you can’t eliminate the hazard, or substitute a less hazardous thing, then engineering out the hazard (like Rust did) is preferable to a procedural control (“git gud at engineering”).

C/C++ does not care and they’re currently the language for foundational work (OS, platforms, and libraries). Python and Java does not care, they will just throw runtime exceptions and crash. Rust care, but they don’t play well with the rest of the world.

rust is currently making its way into linux kernel, core contributors even did rust conf talks...windows already has rust going into kernel and core libraries, osx is also adopting rust, its making its way into all those 'foundational works' you're talking about.. so i'm pretty confused what you are saying

Re: My thoughts on the Bun Rust rewrite

#228

When I read about the bun rewrite I thought no sh*t, those are the exactly the types of bugs I would expect when doing a line by line rewrite of a program in a GC language to memory managed. I was unimpressed with the engineering from the blog, and I'm not surprised to read andrew say they claimed no fuzz testing. I know someone who interviewed at bun when it was less than 10 people (around 5 he said). Allegedly jare…

I think I'm missing something; neither zig nor rust are GC languages. Did bun originally start off in javascript or something, and the rewrite you're referring to is from JS to zig?

Re: My thoughts on the Bun Rust rewrite

#229

Earlier quoted context omitted.

> It's insane to me that Andrew thinks this post will somehow exonerate Zig when it really just makes them look childish. Antirez made a post equivalent to: you'd be a fool not to use AI to increase test coverage. Zig on the other hand has embarrassingly low test coverage given its adoption and time in development. Their stance on AI is completely childish. They could benefit massively from it, yet refuse to even con…

Childish or no, anti-AI sentiment is ubiquitous and growing. From a PR perspective there’s a lot to gain in the short term by picking the “anti-AI” lane. And you can always change your mind later.

It's ubiquitous among dinosaurs. Don't worry. They will be left behind.

Re: My thoughts on the Bun Rust rewrite

#230
post #151

Is the bun rewrite actually done? There's no tag for the release, and as it stands robobun has almost 1.3k open PRs on the repo: https://github.com/oven-sh/bun/pulls/robobun It doesn't look done. And it looks like work on the rewrite began in early may: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573... So... its more like a 2 month rewrite that is definitely not done yet????

From the rewrite to Rust article: > Bun v1.3.14 was the last version of Bun written in Zig. Bun v1.4.0 will be the first version of Bun written in Rust. It's available in canary now. It's also been shipping with Claude Code since June 17th.

It's been shipping in the company that's success is partly contingent on it shipping? But there's no release? Curious.
Post reply on HN