> 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 the largest number of pull requests I’ve seen.
Terrible argument, and not really an argument at all.
> The biggest worry is, of course, the code itself.
I agree, so look at the code and point out what's wrong with it.
Insofar as Andrew Kelley is concerned, it's obvious he has an axe to grind and is salty about Bun embarassing Zig (which he freely admits). Not sure why you'd invoke an unreliable narrator as some sort of final nail in the coffin.
That was 11,000 lines of dead code removed from pre-rust Bun. In a million lines of vibed Rust Bun I'd be astonished if there was a mere 11,000 unused LoC. Noticing unused code isn't a strength of LLMs in my experience.
First of all, I'd need to see a diff on that. It's insane to make that kind of claim without backing it up. Second of all, dead code (as in truly dead code: like an if statement that is guaranteed to never be true), is optimized away by the compiler. So even if we had all this dead code, it is not an issue that would ever impact the final product. Third of all, the Bun runtime consists of over a million lines of code, so that figure (again, even if true) is insignificant.
> It's insane to make that kind of claim without backing it up.
A bizarre accusation. It's a fork of Bun that says they removed the dead code. All you have to do to see the diffs is look at its history. Most of the commits are code removal.
It's a fork of Zig bun, though, not Rust, so hardly relevant to the AI argument.
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".
Bun has been nothing but amazing wins for me, and I really like what it enabled me to do. Two examples:
- I have a couple of projects that handle images. I was including Sharp, but since these are side projects in a small VM, often a redeploy that recompiled Sharp just crashed the full VM (out of memory). Bun includes Bun.Image[1] natively, which is built around Sharp's API, so swapping Sharp out was very easy, and now deploys are a breeze (and swapping it in would be just as easy).
- Bun's JSX support is a godsend. I've replaced almost all my side projects that were backend rendered from Pug, Handlebars, and other various templates I used to have to just pure JSX. Heck, this made it trivial to make a side projects where the Favicon was a dynamic SVG [2]
This reads as another weirdly personal attack against Jarred for slighting a technology stack the author prefers, citing the even weirder personal attack against Jarred written by Andrew Kelley as the sole source to justify their "biggest worry", code quality.
That's a fair criticism... they move slower but mostly because they were the first. They would have to build a new Server and Request/Response primitives from scratch, or deprecate what they already have, or somehow shoehorn the existing types into the new ones.
So I don't think they're opposed to standardising, but it's trickier when you have some past cruft built up. Lets not forget that the fetch() standard was built for browsers, and is a bit of a stretch to make it work on servers at all. You have to diverge from the fetch spec to even make it make sense in a server environment (with things like Cookies handling off the top of my head).
Same thing can be said about Streams in Node.js as well. They had a working streams implementation before the Web Streams API was in browsers (iirc). So implementing the standard now means removing what's already there, or breaking a lot of existing code.
Which leads to confusing things like the fact that there are two streams APIs in Node now:
Fwiw I think it's good they're not removing the legacy code, but they should probably do a big cleanup major release and lean into the modern standards and remove the old stuff. But there's obviously push back in doing so... and probably stuff you can do in the old modules that you can't do in the new and vice versa.
It consolidates a lot of really annoying nits and quality of life aspects like bundling, module resolution, testing, env handling, etc. Node is just the runtime and still would require libs like esbuild, jest/vitest, dotenv, and so on. It's genuinely nice to have those out of the box, and generally in Bun the performance is quite significantly better in places that matter.
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.
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 could be. Another 1/2 job.
Many more examples in many areas but anything Node tries to do itself feels 1/2 baked.
Bun and Deno are faster than Node because it is a 1/2 job at its core. It has v8. It has the tools. It could be done but no. It did nothing for years until Deno and Bun came on the scene to nudge it.
This reads like one of thouse articles in mainstream media where the author has a obvious agenda, and they think they are really clever when they write an attack piece that they think looks like objective , when it really really transparently isent.
Yet another clickbait making outrageous assertions. Fwiw I don’t think anyone’s reputation is on the line and so far, you’ve offered only anecdotal evidence at best. Things like this should be backed by stats and community surveys and a whole lot more. I didn’t see anything about number of downloads or any of the usual metrics used to judge software these days
Your whole scientific endeavor in this seemed to thrive on the rock solid foundation of tweets.
And all those referencing of the Kelly post makes this even more of a clickbait. All you had was to put all the ingredients of a post that will draw the crowd but offer very little on the subject matter it purported to discuss
> Our conclusion is deliberately modest: under the conditions Prisma Compute cares about, the Rust rewrite behaved better than the stable release we had been testing. That was enough to change what we shipped.
> 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 the largest number of pull requests I’ve seen.
Terrible argument, and not really an argument at all.
> The biggest worry is, of course, the code itself.
I agree, so look at the code and point out what's wrong with it.
Insofar as Andrew Kelley is concerned, it's obvious he has an axe to grind and is salty about Bun embarassing Zig (which he freely admits). Not sure why you'd invoke an unreliable narrator as some sort of final nail in the coffin.
Unused code is one issue. A project called Buz[1] found over 11,000 lines of dead code from the Rust port.
[1]: https://github.com/jazzzooo/buz
That was 11,000 lines of dead code removed from pre-rust Bun. In a million lines of vibed Rust Bun I'd be astonished if there was a mere 11,000 unused LoC. Noticing unused code isn't a strength of LLMs in my experience.
11k out of a million. I wish I had a project under 1% of "dead code".
there are linters that check for dead code (depending on your language / ecosystem), it should always be 0%
The dead code was removed from the pre-Rust Zig version. The OP has no credibility.
P.S. Nor does new user parenting my comments.
Flag the article and move on.
First of all, I'd need to see a diff on that. It's insane to make that kind of claim without backing it up. Second of all, dead code (as in truly dead code: like an if statement that is guaranteed to never be true), is optimized away by the compiler. So even if we had all this dead code, it is not an issue that would ever impact the final product. Third of all, the Bun runtime consists of over a million lines of code, so that figure (again, even if true) is insignificant.
> It's insane to make that kind of claim without backing it up.
A bizarre accusation. It's a fork of Bun that says they removed the dead code. All you have to do to see the diffs is look at its history. Most of the commits are code removal.
It's a fork of Zig bun, though, not Rust, so hardly relevant to the AI argument.
Congrats on completely undermining your own argument and credibility. Did you not even read your link?
> Buz is an early-stage experimental fork of pre-Rust Bun.... Over 11,000 lines of dead code removed from upstream Bun.
> how have the last few months not looked good for Bun, exactly?
The article answers this. hint: they're not shipping.
> I get it, you don't like AI or you like Zig over Rust, or whatever
The article doesn't argue for either of these. hint: it's arguing that the team is not shipping.
> Terrible argument, and not really an argument at all.
It's an argument for the devs not shipping
> I agree, so look at the code and point out what's wrong with it.
It's not being shipped.
Hope that helps.
> It's not being shipped.
What are you talking about? I'm running 1.4 canary (the Rust rewrite) right now.
Hope that helps.> What are you talking about?
I think GP was pointing out how bun's release cadence stalled and the project is going nowhere at the moment.
https://github.com/oven-sh/bun/releases
The project was pretty healthy up to 1.13.14, but since may they stopped shipping anything.
That's quite odd for a project that just went through a major rewrite and is lauded as being developed primarily by LLM coding assistants.
Personally I expected the release cadence was going to go through the roof, but instead it flat lined.
> 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.
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".
Bun has been nothing but amazing wins for me, and I really like what it enabled me to do. Two examples:
- I have a couple of projects that handle images. I was including Sharp, but since these are side projects in a small VM, often a redeploy that recompiled Sharp just crashed the full VM (out of memory). Bun includes Bun.Image[1] natively, which is built around Sharp's API, so swapping Sharp out was very easy, and now deploys are a breeze (and swapping it in would be just as easy).
- Bun's JSX support is a godsend. I've replaced almost all my side projects that were backend rendered from Pug, Handlebars, and other various templates I used to have to just pure JSX. Heck, this made it trivial to make a side projects where the Favicon was a dynamic SVG [2]
[1] https://bun.com/docs/runtime/image
[2] https://stocksreader.com/portfolio?%5Egspc=10&amzn=10&msft=1...
I also use Bun.Image to collect image size and metadata, and also to generate low-quality image placeholders. Works great.
Have you tried 1.4?
This reads as another weirdly personal attack against Jarred for slighting a technology stack the author prefers, citing the even weirder personal attack against Jarred written by Andrew Kelley as the sole source to justify their "biggest worry", code quality.
Idk why people have become so invested in this.
The OP says
> Unused code is one issue. A project called Buz[1] found over 11,000 lines of dead code from the Rust port. [1]: https://github.com/jazzzooo/buz
When in fact Buz is a fork of the pre-Rust Zig version of Bun.
The OP has no credibility.
I've been a heavy user of Bun since 2022. The last three months of their public timeline have not looked good, so I wanted to summarize my frustration
Then simply say this, and no need to have a clickbait title?
> Bun 1.4 Rust rewrite is not looking good
This is.. clickbait ?
Sure - the implication that the rust rewrite is technically bad, which is not what the article is about.
What is the right recommendation at this point for a Node alternative? Deno?
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/
That's a fair criticism... they move slower but mostly because they were the first. They would have to build a new Server and Request/Response primitives from scratch, or deprecate what they already have, or somehow shoehorn the existing types into the new ones.
They do seem to have just merged in support for Web Workers though, which I've been following for a while: https://github.com/nodejs/node/issues/43583
So I don't think they're opposed to standardising, but it's trickier when you have some past cruft built up. Lets not forget that the fetch() standard was built for browsers, and is a bit of a stretch to make it work on servers at all. You have to diverge from the fetch spec to even make it make sense in a server environment (with things like Cookies handling off the top of my head).
Same thing can be said about Streams in Node.js as well. They had a working streams implementation before the Web Streams API was in browsers (iirc). So implementing the standard now means removing what's already there, or breaking a lot of existing code.
Which leads to confusing things like the fact that there are two streams APIs in Node now:
Streams: https://nodejs.org/docs/latest/api/stream.html
Web Streams: https://nodejs.org/docs/latest/api/webstreams.html
And they have to support going back and forth between the two: https://nodejs.org/docs/latest/api/webstreams.html#nodejs-st...
It's exactly the same story for crypto as well. Node created it's own standard, Web standards emerged, Node has to support both:
https://nodejs.org/docs/latest/api/crypto.html
https://nodejs.org/docs/latest/api/webcrypto.html
Fwiw I think it's good they're not removing the legacy code, but they should probably do a big cleanup major release and lean into the modern standards and remove the old stuff. But there's obviously push back in doing so... and probably stuff you can do in the old modules that you can't do in the new and vice versa.
It consolidates a lot of really annoying nits and quality of life aspects like bundling, module resolution, testing, env handling, etc. Node is just the runtime and still would require libs like esbuild, jest/vitest, dotenv, and so on. It's genuinely nice to have those out of the box, and generally in Bun the performance is quite significantly better in places that matter.
Let me address each one in turn:
- esbuild - this is normally for TS compilation, which Node can run natively now by stripping types: https://nodejs.org/docs/latest/api/typescript.html#type-stri...
- jest/vitest: Node has a test runner: https://nodejs.org/docs/latest/api/test.html
- dotenv: Node can read .env files: https://nodejs.org/docs/latest/api/cli.html#--env-filefile
Performance, maybe you're right - but if you're doing any IO, I doubt the runtime is really the bottleneck.
What’s wrong with node? Genuine question
Nothing. Bun is just smaller and faster and comes with a built-in package manager, test runner, bundler, SQL engine, image processor etc..
I think npm install can be very very slow on large projects. Think minutes.
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.
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 could be. Another 1/2 job.
Many more examples in many areas but anything Node tries to do itself feels 1/2 baked.
Bun and Deno are faster than Node because it is a 1/2 job at its core. It has v8. It has the tools. It could be done but no. It did nothing for years until Deno and Bun came on the scene to nudge it.
I'm still waiting for v1.4 as I have committed to Bun so much. Not looking good, though.
Not that my opinion matters much, but I like Deno. I never tried Bun.
imo, node is fine, they have done a lot to improve and the menagerie of js runtimes have largely converged
This reads like one of thouse articles in mainstream media where the author has a obvious agenda, and they think they are really clever when they write an attack piece that they think looks like objective , when it really really transparently isent.
Based on my experience so far, code written by today’s frontier LLM is generally trustworthy, though it still requires human oversight.
Yet another clickbait making outrageous assertions. Fwiw I don’t think anyone’s reputation is on the line and so far, you’ve offered only anecdotal evidence at best. Things like this should be backed by stats and community surveys and a whole lot more. I didn’t see anything about number of downloads or any of the usual metrics used to judge software these days
Your whole scientific endeavor in this seemed to thrive on the rock solid foundation of tweets.
And all those referencing of the Kelly post makes this even more of a clickbait. All you had was to put all the ingredients of a post that will draw the crowd but offer very little on the subject matter it purported to discuss
The article is about the upcoming 1.4 release.
The article lists various promised release dates, are they incorrect?
Counterpoint:
> Our conclusion is deliberately modest: under the conditions Prisma Compute cares about, the Rust rewrite behaved better than the stable release we had been testing. That was enough to change what we shipped.
https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute