Bun 1.4 Rust rewrite is not looking good? • Hacker News Board

Re: Bun 1.4 Rust rewrite is not looking good?

#51

Post by locknitpicker » Wed, Aug 19, 2026, 9:34 AM UTC

dvt wrote: post #4

> The last three months have not looked good for Bun. Apart from pro-AI or anti-AI posturing how have the last few months not looked good for Bun, exactly? I use it daily and I've seen basically zero regressions. I get it, you don't like AI or you like Zig over Rust, or whatever. I just haven't seen any serious argument that Bun has somehow become worse software. > The project has over 5k open pull requests, which is…

> Apart from pro-AI or anti-AI posturing how have the last few months not looked good for Bun, exactly?

The blog post states quite clearly that Bun stopped posting any release.

During the Zig/pre-Rust days, Bun was posting s new release each 2-3 weeks.

Since then, Bun's Rust migration is correlated with a complete stop of Bun's release cadence.

Re: Bun 1.4 Rust rewrite is not looking good?

#52

Post by 0-bad-sectors » Wed, Aug 19, 2026, 10:04 AM UTC

I think this is a great chance for us to evaluate how capable AI is and at what cost does it deliver such capabilities.

I would love to know how much token they spent on the rewrite starting from deciding to rewrite till they actually ship. I assume since the beginning of this whole rewrite saga they have been spending tokens on it every day so the number that Jarred mentioned in his blog post has increased a lot since then.

Also assuming the future releases will be done through AI as well I wonder how much it will cost for each of them.

Re: Bun 1.4 Rust rewrite is not looking good?

#53

Post by re-thc » Wed, Aug 19, 2026, 11:19 AM UTC

aureate wrote: post #47

re-thc wrote: post #24

Earlier quoted context omitted.

> The article answers this. hint: they're not shipping. They're shipping though. Claude Code and many others use it. There's just not been a "public" release.

In other words, it hasn't shipped. The bun rewrite is looked to as proof that this sort of full-throttle vibecoding is the future of software development, at least for large porting projects like this one, and for many people on this site that is a high stakes question. To prove that, a proper release is needed, and the Bun community needs to adopt it. There's a huge partisan eagerness to declare the Claude Code rele…

> The bun rewrite is looked to as proof that this sort of full-throttle vibecoding is the future of software development

To who? You?

> To prove that, a proper release is needed

For who? Who is trying to prove what?

> It's Jarred that keeps saying it'll be released tomorrow

There's no official blog... he's just rambling on x?

> Github insights for the last week

That's the problem with the rest of your post. Bun is no longer VC-fueled open source project. It got sold to Anthropic.

> There's a huge partisan eagerness to declare the Claude Code release

Hence there isn't. The Claude Code release is for its own use.

Re: Bun 1.4 Rust rewrite is not looking good?

#54

Post by aureate » Wed, Aug 19, 2026, 11:22 AM UTC

re-thc wrote: post #53

aureate wrote: post #47

Earlier quoted context omitted.

In other words, it hasn't shipped. The bun rewrite is looked to as proof that this sort of full-throttle vibecoding is the future of software development, at least for large porting projects like this one, and for many people on this site that is a high stakes question. To prove that, a proper release is needed, and the Bun community needs to adopt it. There's a huge partisan eagerness to declare the Claude Code rele…

> The bun rewrite is looked to as proof that this sort of full-throttle vibecoding is the future of software development To who? You? > To prove that, a proper release is needed For who? Who is trying to prove what? > It's Jarred that keeps saying it'll be released tomorrow There's no official blog... he's just rambling on x? > Github insights for the last week That's the problem with the rest of your post. Bun is no…

None of that makes any sense whatsoever.

Re: Bun 1.4 Rust rewrite is not looking good?

#55

Post by happytoexplain » Wed, Aug 19, 2026, 11:28 AM UTC

skeledrew wrote: post #28

I'm still waiting for someone to bring forth some reproducible stats and state something along the lines of "I did a comparison of Bun 1.3 vs 1.4, and found these user-affecting issues in the latter which are not in the former".

[flagged]

Re: Bun 1.4 Rust rewrite is not looking good?

#56

Post by pjmlp » Wed, Aug 19, 2026, 11:38 AM UTC

franciscop wrote: post #32

domh wrote: post #15

Earlier quoted context omitted.

What's wrong with just using Node? It's stable, has a good (and growing) standard library and has enough backing to be self sustaining. edit: There's also nub which is built on top of Node.js and removes some rough/legacy edges: https://github.com/nubjs/nub

Node.js is virtually the only platform not supporting the Fetchable convention: https://github.com/nodejs/node/issues/63096 https://fetchable.org/

I wasn't even aware it exists, so no big problem.

Re: Bun 1.4 Rust rewrite is not looking good?

#57

Post by pjmlp » Wed, Aug 19, 2026, 11:39 AM UTC

Mashimo wrote: post #37

rienbdj wrote: post #17

Earlier quoted context omitted.

What’s wrong with node? Genuine question

I think npm install can be very very slow on large projects. Think minutes.

Use pnpm or yarn, also available with node.

Re: Bun 1.4 Rust rewrite is not looking good?

#58

Post by pjmlp » Wed, Aug 19, 2026, 11:40 AM UTC

kwhat4 wrote: post #38

rienbdj wrote: post #17

Earlier quoted context omitted.

What’s wrong with node? Genuine question

From the perspective of someone trying to package nodejs, building it is a complete dumpster fire. GYP (generate your projects) is a now defunct and poorly thought out build tool that node heavily relies on with it's native C/C++ modules. Cross compiling is completely broken and I am honestly surprised it builds reliability for the native target.

C++ addons are great, that is what makes JavaScript on the server bearable, when performance matters and we're stuck with it, instead of using Go, Rust, Java, .NET.

Re: Bun 1.4 Rust rewrite is not looking good?

#59

Post by pjmlp » Wed, Aug 19, 2026, 11:41 AM UTC

re-thc wrote: post #41

rienbdj wrote: post #17

Earlier quoted context omitted.

What’s wrong with node? Genuine question

It's 1/2 baked in everything it tries to do. You need a "separate" tool called npm to install packages. It's dead slow so they added corepack. Another extra tool. Then you use it to install yarn or pnpm. Another extra tool. It might still be slower than bun... In the past you need to transpile typescript with other tools. It can only run js out of the box. The later fix was a wasm build, which means slower than it co…

So JavaScript in general.

Re: Bun 1.4 Rust rewrite is not looking good?

#60

Post by myvoiceismypass » Wed, Aug 19, 2026, 2:31 PM UTC

dminik wrote: post #48

verdverm wrote: post #18

Earlier quoted context omitted.

there are linters that check for dead code (depending on your language / ecosystem), it should always be 0%

I mean, how do you check that your frontend code (possibly not even managed by your team) is calling and needs all of your backend endpoints? I'm sure it can be done, and it probably should, but saying it should always be 0% is not very pragmatic.

Dead code likely means chunks of code not used by other chunks of code, which should be easy to determine statically in most modern languages. Whether an exposed endpoint is being hit (used) or not as an API is more of a test-code-coverage thing, different from the concept of "dead code".