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".
For the internet at large no, but the comment doesn't make sense. It's not as if volunteers don't post all kinds of checks, and reports, and benchmarks, and deep dives anyway.
I would assume Sapolsky understands how terms are defined by their context, and that someone saying “free will” in a forum discussion about software doesn’t literally imply the strictest, academic definition of the term.
I'm curious as to what other definitions of the term exist, other than the academic one? I had never though of using the term in any other context. But maybe that's because I've been concerning myself with this specific topic for too long.
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.
People _really_ don't want there to be success stories for llms and they will go through all lengths to discredit and disparage folks successfully exploring the space.
The most obvious benefit Rust can give them is being safe from memory leaks. This is hardly controversial: it has been a Zig design choice that memory leaks are the developer/user's responsibility. They have already demonstrated to have fixed several of those [0].
Marketing-wise, it has been an obvious success. Dunno if that matters.
Yes? I’ve made that mistake, it’s not particularly hard to do. Stash an Arc in something that lives too long, or forget to clear its inner data structure when you should, and you have a leak.
That’s not like … a design flaw or something, just a common class of error Rust can’t save you from.
Seems pretty simple to me: if the software works, the port has been successful.
If this is unsatisfactory, another way to think about the question is to ask "what would make you conclude it has failed?" That requires a sharp choice.
Both of these are true. I recall Anthropic's lofty claims about their C compiler. It just did not work, and they claimed all of this and that. It was clear they were driven to believe that agents alone could write a C compiler, and refused to believe they couldn't. Not that I think that AI couldn't write a C compiler. It definitely can... with a human at the helm and sufficient time.
But, for people who don't like AI, they also refuse to believe that AI could be good at any particular workflow. Which is just obviously not true, there are workflows that AI is really good at. Language re-writes are one of them. They're almost mechanical in nature and trivial to check via tests. So, the perfect use-case for an LLM.
I'm not saying the Bun re-write is any good, but the underlying concept is sound. If ever there was a tool to do a language re-write, it would be a high quality LLM.
you really went digging with that 3 months old hn comment. What's wrong with that comment btw? Are you saying he was lying and they did in fact commit to the rewrite at that point?
I didn't dig. It was prominent at the time this occurred, because like I said, it wasn't communicated at all until they were already in the middle of it.
And yes, I think he was not genuine there and that they had indeed fully committed to the rewrite prior to that point and comment.
If you're not aware of any of this, how are you arguing it was communicated clearly?
I'm really skeptical about this rewrite
I chose to adopt bun about a year ago, and I've honestly lost count of the number of issues i've submitted and the amount of time i've wasted dealing with them. If I had to make the choice again, I would probably stick with node and pnpm for serious projects
We're constantly being sold on promises of -XX% ram usage, but in practice, it's often builds randomly failing for no apparent reason, memory leaks bringing applications down, and instability that ends up costing far more in engineering time than the resources saved
That's why i'm worried that bun 1.4 could end up being a step backwards, once again putting into question the small amount of stability we've managed to achieve so far
But I still strongly believe the project makes a lot of sense, and I genuinely think these issues can be solved by 2028, if the project keeps its focus on stability instead of another SDK for SQL, web sockets, image compression, or whatever comes next
> But I still strongly believe the project makes a lot of sense, and I genuinely think these issues can be solved by 2028, if the project keeps its focus on stability instead of another SDK for SQL, web sockets, image compression, or whatever comes next
If you check the maintainer X, he's asking Claude for what features to implement next. Not only stabilizing isn't the priority, even the features implemented are random.
What does innocent even mean in this context? I don't care if it's innocent. It is. Naivy too. But millions of people use the system and were expecting stability, not it to be a random AI experiment.
> If you check the maintainer X, he's asking Claude for what features to implement next. Not only stabilizing isn't the priority, even the features implemented are random.
To me that sort of stunt sounds like blatant attempts to distract the audience away from relevant topics.
Indeed. This article didn't age well... I'm sure that the creator of the original piece will do a thoughtful self-analysis if they might have gotten something wrong, and make sure they didn't have any sort of unspoken bias in their thinking and writing!
> 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.
All that sounds great. The promised of shipping for months that never came is a concern, comparatively speaking to history of the project and what is happening. But if we have user feedback suggest otherwise may be it is good.
For most, they are still waiting for official release so they could make their own judgment, the problem is that it is still not released. I guess we should just wait a little longer.
>> 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.
Technically, maybe.
But when you consider for a moment that in this pile of slop some PRs were crafted by actual people who trusted Bun and Jarred... and whose trust has been flushed down the toilet by the Rust rewrite. Well, maybe that's the price of progress. Or maybe that's a grave mistake.
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 release or anecdotal experiences on the canary as victory, but the viability of 1.4 hasn't been demonstrated until it has been released and adopted by the bulk of the community.
There isn't actually any hurry on that. Nobody needs Bun 1.4 tomorrow. It's Jarred that keeps saying it'll be released tomorrow, while the code churns at an astonishing rate (see below). People with a skeptical outlook will inevitably suspect that he doesn't have confidence in the release and is struggling to acquire it.
Github insights for the last week:
> Excluding merges, 57 authors have pushed 349 commits to main and 6892 commits to all branches.
> On main, 2026 files have changed and there have been 189,502 additions and 133,836 deletions
Sure but that’s how you beta test a runtime, by using it in a codebase you control. Claude is publicly released and used widely, that’s still only a single codebase
So they are being more cautious and spending more time on polish after a never been done before historical massive rewrite...? Stop the press! They are not shipping as fast they used to! Omg!
> So they are being more cautious and spending more time on polish after a never been done before historical massive rewrite...?
That's not credible at all. I mean, after a major release there are tons of low-priority low-hanging fruit issues that can be quickly sorted out. That's the nature of a release process.
However, Bun stopped releasing anything. Even after lauding it's AI push,which can easily chomp through small tickets.
It's been a couple of months since the major push. I repeat: the release cadence of a mature, stable codebase as the Zig one was at 2-3 weeks. A messy rust rewrite packed with unsafe code, which is prime ground for small bugfixes and correctness fixes, led the project to grind to a halt.
Not surprising, but Jarred has been teasing "tomorrow I swear" for months and Bun keeps missing his own deadlines.
There's clearly something wrong in their confidence about Rust Bun: If it isn't ready they should have said "whenever it's done", and if it is they'd have met some deadline by now. I suspect the speed was supposed to be part of the stunt, yet they seem to have encountered the 90:90 rule.
The rewrite was a lot faster. Actually shaking out the bugs from the rewrite (or just getting enough confidence in the new version from use by early adopters) is probably not going to be drastically faster.
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.
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".
True, but Bun actually has a similar problem. It's creating bindings to a JS runtime. If the JS glue code then no longer uses it, the code is still marked as alive because it's registered with the runtime.
In a previous life I managed to deliver a system with (basic-block) coverage measurement compiled in (gcov) but instead of the mess of files gcov generates, the whole coverage structure was streamed to a remote server (it compressed very well). Once that was in place it was an amazing telemetry tool.
Later on used Intel Processor Trace in a similar fashion for even finer (mc-dc) coverage.
Coverage tools are very useful, if a bit hard to use...
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.
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.
For me the real test will be maintainability going forwards. Not a JS user.
I suppose it’s one thing to rewrite code and make tests pass. But a lot of my own CPU cycles when coding go to making the code understandable, modular, editable etc. IME Claude is not great on these.
Maybe it doesn’t matter? Maybe the spaghetti makes sense to Claude, and when you say “hey add this feature”, no problem?
But maybe it will turn into a worse ball of spaghetti, with no nicely curated tests, hacks on hacks on hacks and never ending loops of whackamole of “just change this one line and rerun tests”.
They were pleased to be faster than Go in the "Hello World" benchmark, but unfortunately, they lag behind Node.js and Deno in complex real-world workloads.
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]
Lots of people are apparently happily using the canary version in prod. Anthropic has been using it for ages now, as has Prisma.
Why not release 1.4 (or 2.0 or whatever) then? It won't get picked up by lots of tooling and won't get allowed in many "no pre-release in prod" shops until then. It had plenty of issues before (many thousands of open issues) so a few thousand more is hardly a big deal...
No, the article shows that Jarred is claiming to be working on releasing it. And maybe he is, but he's also not provided reasons for the repeated delays, so for all we know he's goofing off drinking pina colladas while Claude is running the show and Tweeting on his behalf.
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.
Yes, I've dealt with streams a lot and I've seen the pain. I'd say it's the 2nd biggest "compat breaking" of Node/JS after the require vs esm, but while the require vs esm is mostly gone (we all use esm nowadays, except for aham the default npm) the stream types I expect will last for a long while since that's not so "high" in the productivity list for most. Also, that's actually one of the main pains I have with Node NOT supporting Fetchable, the fact that the Body is not a Readable.
When we used to code by hand, Bun used to have an amazing list of articles on how to convert from almost any kind of streamable to almost any other type. I used it a lot, and that was when I started liking Bun so much.
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.
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.
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.
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.
Jarred wrote a lengthy blog about the rewrite a little while ago and IIRC the token burn numbers were in there (or at least the burn up to that point in time).
I think the rewrite will end up being more expensive (for the same quality) because AI was used.
At the same time this specific rewrite is being used to drive the narrative that reading the code is counterproductive.
If they had delivered their promises, they might have convincingly delivered that argument.
...but the cost keeps going up and up and up and up! If it was only the token costs it might still be economically viable, but I'm imagining that when you add in the pro-rated salaries of the human engineers this would start to look like a financial blunder even if it released today.
It's true that I don't want a success story told about a failure, because then replicating the "success" would likely produce lots more bad outcomes
This remains one of the strangest and frankly most annoying beefs I’ve ever read about all decade, and I say this as somebody with no particular affinity for bun, rust, or zig.
I'm quietly hoping it fails. This will once and for all silence all those paid-shills that are calling out that A.I. will replace all software developers.
It may also lead to the A.I. musical chairs game stopping and a multi-trillion dollar collapse of the stock-market and, most likely, the financial system. Hopefully we'll be able to buy DRAM and other stuff that uses it cheaply again.
I mean there's so much cruft on the internet about people talking how revolutionary these code generators are and that they fixed 5 years worth of technical debt in 2 months etc. etc. Considering the multi-trillion dollars involved I don't believe we can trust anything we read anymore. Many of these proponents are nothing but paid shills.
> 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.
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
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".
Is it a paid job?
Paid to make such a post? No, but Bun has real users. If there are real issues in 1.4, surely someone will come out.
Here... I'll go first. `bun repl` in 1.4-canary has some rendering issues where characters get overwritten that I had previously not observed in 1.3.
For the company making the port, it should be.
For the internet at large no, but the comment doesn't make sense. It's not as if volunteers don't post all kinds of checks, and reports, and benchmarks, and deep dives anyway.
can I do it with AI?
You have free will
Robert Sapolsky would disagree
I would assume Sapolsky understands how terms are defined by their context, and that someone saying “free will” in a forum discussion about software doesn’t literally imply the strictest, academic definition of the term.
But if not he can reach out
I'm curious as to what other definitions of the term exist, other than the academic one? I had never though of using the term in any other context. But maybe that's because I've been concerning myself with this specific topic for too long.
In colloquial parlance that means “it’s up to you, you can do what you want and don’t need permission”
If there isn't free will, he doesn't really disagree.
He just says whatever predetermined shit he was supposed to say.
[flagged]
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.
Jarred has probably already sold his company for big $$$ and is set up for life whether the Bun rewrite succeeds or not.
We will, however, be left to scour the ruins of the financial devastation if this goes sour.
> Jarred has probably already sold his company for big $$$
He _has_ sold, though. Anthropic purchased Oven back in Dec. 2025.
Or your probably was about whether it was big $$$ or not?
It was a rhetorical question, actually.
It wasn't a question at all
People _really_ don't want there to be success stories for llms and they will go through all lengths to discredit and disparage folks successfully exploring the space.
It is yet to be determined whether or not the bun rewrite is a success, though.
Right. So let's hold our horses and wait for the release before disparaging anyone.
I do have to agree with the author about Jarred's false claims about release dates though. Really not sure why he keeps doing that.
What are the standards for determining that?
The most obvious benefit Rust can give them is being safe from memory leaks. This is hardly controversial: it has been a Zig design choice that memory leaks are the developer/user's responsibility. They have already demonstrated to have fixed several of those [0].
Marketing-wise, it has been an obvious success. Dunno if that matters.
[0] https://bun.com/blog/bun-in-rust
Rust also doesn't prevent memory leaks: you can create memory leaks through reference cycles just fine in rust.
Who cares?
People who don’t want to run out of memory?
Are the Rust programmers who suffered from memory leaks through reference cycles in the room with you right now?
Yes? I’ve made that mistake, it’s not particularly hard to do. Stash an Arc in something that lives too long, or forget to clear its inner data structure when you should, and you have a leak.
That’s not like … a design flaw or something, just a common class of error Rust can’t save you from.
> What are the standards for determining that?
Seems pretty simple to me: if the software works, the port has been successful.
If this is unsatisfactory, another way to think about the question is to ask "what would make you conclude it has failed?" That requires a sharp choice.
> Marketing-wise, it has been an obvious success. Dunno if that matters.
What's interesting tho it's that it can go from apparent marketing success to a big failure as the release keeps getting postponed.
Seems like they just released 1.4 though.
Great! It's finally Monday.
Watch this:
People _really_ want there to be success stories for llms and they will go through all lengths to discredit and disparage folks questioning the space.
Both of these are true. I recall Anthropic's lofty claims about their C compiler. It just did not work, and they claimed all of this and that. It was clear they were driven to believe that agents alone could write a C compiler, and refused to believe they couldn't. Not that I think that AI couldn't write a C compiler. It definitely can... with a human at the helm and sufficient time.
But, for people who don't like AI, they also refuse to believe that AI could be good at any particular workflow. Which is just obviously not true, there are workflows that AI is really good at. Language re-writes are one of them. They're almost mechanical in nature and trivial to check via tests. So, the perfect use-case for an LLM.
I'm not saying the Bun re-write is any good, but the underlying concept is sound. If ever there was a tool to do a language re-write, it would be a high quality LLM.
It isn't LLMs in general, from what I can tell. It was how this port was done and communicated.
It was communicated fine, can you be more specific ?
No, it wasn't. For example: https://news.ycombinator.com/item?id=48019226
you really went digging with that 3 months old hn comment. What's wrong with that comment btw? Are you saying he was lying and they did in fact commit to the rewrite at that point?
I didn't dig. It was prominent at the time this occurred, because like I said, it wasn't communicated at all until they were already in the middle of it.
And yes, I think he was not genuine there and that they had indeed fully committed to the rewrite prior to that point and comment.
If you're not aware of any of this, how are you arguing it was communicated clearly?
but, importantly, it is not the main reason why people are skeptical of bun rewrite right
I'm really skeptical about this rewrite I chose to adopt bun about a year ago, and I've honestly lost count of the number of issues i've submitted and the amount of time i've wasted dealing with them. If I had to make the choice again, I would probably stick with node and pnpm for serious projects We're constantly being sold on promises of -XX% ram usage, but in practice, it's often builds randomly failing for no apparent reason, memory leaks bringing applications down, and instability that ends up costing far more in engineering time than the resources saved That's why i'm worried that bun 1.4 could end up being a step backwards, once again putting into question the small amount of stability we've managed to achieve so far
But I still strongly believe the project makes a lot of sense, and I genuinely think these issues can be solved by 2028, if the project keeps its focus on stability instead of another SDK for SQL, web sockets, image compression, or whatever comes next
> But I still strongly believe the project makes a lot of sense, and I genuinely think these issues can be solved by 2028, if the project keeps its focus on stability instead of another SDK for SQL, web sockets, image compression, or whatever comes next
If you check the maintainer X, he's asking Claude for what features to implement next. Not only stabilizing isn't the priority, even the features implemented are random.
> If you check the maintainer X, he's asking Claude for what features to implement next.
Link?
> Link?
https://xcancel.com/jarredsumner/status/2089183223024943505
Thanks. Seems pretty innocent to me.
What does innocent even mean in this context? I don't care if it's innocent. It is. Naivy too. But millions of people use the system and were expecting stability, not it to be a random AI experiment.
> If you check the maintainer X, he's asking Claude for what features to implement next. Not only stabilizing isn't the priority, even the features implemented are random.
To me that sort of stunt sounds like blatant attempts to distract the audience away from relevant topics.
There's a lot riding on this. If the Bun rewrite fails it could lead to the U.S. and global financial system collapsing. Yes, incredible, but true.
Bun 1.4 released: https://bun.com/blog/bun-v1.4 and https://github.com/oven-sh/bun/releases/tag/bun-v1.4.0
Indeed. This article didn't age well... I'm sure that the creator of the original piece will do a thoughtful self-analysis if they might have gotten something wrong, and make sure they didn't have any sort of unspoken bias in their thinking and writing!
> 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.
> 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.
that could just be de rigeur enshittification.
All that sounds great. The promised of shipping for months that never came is a concern, comparatively speaking to history of the project and what is happening. But if we have user feedback suggest otherwise may be it is good.
For most, they are still waiting for official release so they could make their own judgment, the problem is that it is still not released. I guess we should just wait a little longer.
I say let them cook. Rushed software is not good, neither for the user nor the developers. I say the same for Zig 1.0
What I'd like to see in the meantime is what are the biggest blockers to the release. Maybe Bun has a milestone list somewhere, I couldn't find it.
Legitimately curious, are you using the 1.4 canary release in a production environment?
>> 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.
Technically, maybe.
But when you consider for a moment that in this pile of slop some PRs were crafted by actual people who trusted Bun and Jarred... and whose trust has been flushed down the toilet by the Rust rewrite. Well, maybe that's the price of progress. Or maybe that's a grave mistake.
I'm not yet sure which is it.
> 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.
> 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 release or anecdotal experiences on the canary as victory, but the viability of 1.4 hasn't been demonstrated until it has been released and adopted by the bulk of the community.
There isn't actually any hurry on that. Nobody needs Bun 1.4 tomorrow. It's Jarred that keeps saying it'll be released tomorrow, while the code churns at an astonishing rate (see below). People with a skeptical outlook will inevitably suspect that he doesn't have confidence in the release and is struggling to acquire it.
Github insights for the last week:
> Excluding merges, 57 authors have pushed 349 commits to main and 6892 commits to all branches.
> On main, 2026 files have changed and there have been 189,502 additions and 133,836 deletions
> 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.
None of that makes any sense whatsoever.
Pretty simple: it shipped to the owner.
Aka: internal beta
Claude code is for sure the most widely used bun application. So the majority of bun users are using it.
That’s not what I’d call an internal beta?
Sure but that’s how you beta test a runtime, by using it in a codebase you control. Claude is publicly released and used widely, that’s still only a single codebase
I guess Claude too gets stuck on "wait! Let me think this through..." eventually.
Chris Newman fan?
You should have lead with “What is it now?”
> 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.
So they are being more cautious and spending more time on polish after a never been done before historical massive rewrite...? Stop the press! They are not shipping as fast they used to! Omg!
> So they are being more cautious and spending more time on polish after a never been done before historical massive rewrite...?
That's not credible at all. I mean, after a major release there are tons of low-priority low-hanging fruit issues that can be quickly sorted out. That's the nature of a release process.
However, Bun stopped releasing anything. Even after lauding it's AI push,which can easily chomp through small tickets.
It's been a couple of months since the major push. I repeat: the release cadence of a mature, stable codebase as the Zig one was at 2-3 weeks. A messy rust rewrite packed with unsafe code, which is prime ground for small bugfixes and correctness fixes, led the project to grind to a halt.
No one looks good in the picture.
Boo hoo https://bun.com/blog/bun-v1.4
Pretty sure that’s because of the backlash. So, sounds like a good thing people voiced their concerns
I wouldn't consider it particularly surprising that a big rewrite results in no new releases for a bit before the rewritten version is released.
Not surprising, but Jarred has been teasing "tomorrow I swear" for months and Bun keeps missing his own deadlines.
There's clearly something wrong in their confidence about Rust Bun: If it isn't ready they should have said "whenever it's done", and if it is they'd have met some deadline by now. I suspect the speed was supposed to be part of the stunt, yet they seem to have encountered the 90:90 rule.
Isn't supposed to be faster with LLMs?
The rewrite was a lot faster. Actually shaking out the bugs from the rewrite (or just getting enough confidence in the new version from use by early adopters) is probably not going to be drastically faster.
Then it's not a net speed gain?
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.
You cannot be serious, any person with actual professional software experience would laugh at that claim
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".
True, but Bun actually has a similar problem. It's creating bindings to a JS runtime. If the JS glue code then no longer uses it, the code is still marked as alive because it's registered with the runtime.
In a previous life I managed to deliver a system with (basic-block) coverage measurement compiled in (gcov) but instead of the mess of files gcov generates, the whole coverage structure was streamed to a remote server (it compressed very well). Once that was in place it was an amazing telemetry tool.
Later on used Intel Processor Trace in a similar fashion for even finer (mc-dc) coverage.
Coverage tools are very useful, if a bit hard to use...
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.
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.
For me the real test will be maintainability going forwards. Not a JS user.
I suppose it’s one thing to rewrite code and make tests pass. But a lot of my own CPU cycles when coding go to making the code understandable, modular, editable etc. IME Claude is not great on these.
Maybe it doesn’t matter? Maybe the spaghetti makes sense to Claude, and when you say “hey add this feature”, no problem?
But maybe it will turn into a worse ball of spaghetti, with no nicely curated tests, hacks on hacks on hacks and never ending loops of whackamole of “just change this one line and rerun tests”.
I can imagine both - let’s see.
https://x.com/yagiznizipli/status/2082905235459117202
They were pleased to be faster than Go in the "Hello World" benchmark, but unfortunately, they lag behind Node.js and Deno in complex real-world workloads.
3 months since the last stable release feels ... alright. The constant promises for a new stable release feels a bit like a self-own.
Having said that I would have a bit more confidence in things if release just got back to a normal pace.
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?
have you? Type -canary instead of this garbage article
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
This was useful to read, thanks.
[flagged]
> Bun 1.4 Rust rewrite is not looking good
This is.. clickbait ?
[flagged]
Lots of people are apparently happily using the canary version in prod. Anthropic has been using it for ages now, as has Prisma.
Why not release 1.4 (or 2.0 or whatever) then? It won't get picked up by lots of tooling and won't get allowed in many "no pre-release in prod" shops until then. It had plenty of issues before (many thousands of open issues) so a few thousand more is hardly a big deal...
TFA shows that they are working on releasing it.
If you actually want an answer to your question, ask Jarred ... you won't get it here.
No, the article shows that Jarred is claiming to be working on releasing it. And maybe he is, but he's also not provided reasons for the repeated delays, so for all we know he's goofing off drinking pina colladas while Claude is running the show and Tweeting on his behalf.
"for all we know [utterly implausible nonsense]" is intellectually dishonest trash, not a legitimate argument.
bit off topic: do lots of people use Prisma Compute? I never heard it in a conversation, in my bubble
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.
Yes, I've dealt with streams a lot and I've seen the pain. I'd say it's the 2nd biggest "compat breaking" of Node/JS after the require vs esm, but while the require vs esm is mostly gone (we all use esm nowadays, except for aham the default npm) the stream types I expect will last for a long while since that's not so "high" in the productivity list for most. Also, that's actually one of the main pains I have with Node NOT supporting Fetchable, the fact that the Body is not a Readable.
When we used to code by hand, Bun used to have an amazing list of articles on how to convert from almost any kind of streamable to almost any other type. I used it a lot, and that was when I started liking Bun so much.
It also doesn't support the foobaz protocols! But millions of companies are using it to serve millions of customers, and it's fine.
I wasn't even aware it exists, so no big problem.
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.
I'm still waiting for v1.4 as I have committed to Bun so much. Not looking good, though.
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..
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.
So JavaScript in general.
I think npm install can be very very slow on large projects. Think minutes.
Use pnpm or yarn, also available with node.
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.
But why do you need an alternative to node in the first place?
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
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.
Jarred wrote a lengthy blog about the rewrite a little while ago and IIRC the token burn numbers were in there (or at least the burn up to that point in time).
https://bun.com/blog/bun-in-rust
Could have sworn I read this exact article a month ago
I think the rewrite will end up being more expensive (for the same quality) because AI was used.
At the same time this specific rewrite is being used to drive the narrative that reading the code is counterproductive.
If they had delivered their promises, they might have convincingly delivered that argument.
...but the cost keeps going up and up and up and up! If it was only the token costs it might still be economically viable, but I'm imagining that when you add in the pro-rated salaries of the human engineers this would start to look like a financial blunder even if it released today.
It's true that I don't want a success story told about a failure, because then replicating the "success" would likely produce lots more bad outcomes
Based on my experience so far, code written by today’s frontier LLM is generally trustworthy, though it still requires human oversight.
This remains one of the strangest and frankly most annoying beefs I’ve ever read about all decade, and I say this as somebody with no particular affinity for bun, rust, or zig.
I'm quietly hoping it fails. This will once and for all silence all those paid-shills that are calling out that A.I. will replace all software developers.
It may also lead to the A.I. musical chairs game stopping and a multi-trillion dollar collapse of the stock-market and, most likely, the financial system. Hopefully we'll be able to buy DRAM and other stuff that uses it cheaply again.
I mean there's so much cruft on the internet about people talking how revolutionary these code generators are and that they fixed 5 years worth of technical debt in 2 months etc. etc. Considering the multi-trillion dollars involved I don't believe we can trust anything we read anymore. Many of these proponents are nothing but paid shills.
Lol Bun rust-rewrite is still not released even after 3 month :).
This comment aged poorly
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
lmao
need 5 trillion more Opus token
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?
I haven’t verified the dates of the tweets. But it is a huge leap from a delayed release to a major conclusion that “the rewrite is not looking good”.
What "promises"? There were no promises, just some optimistic informal tweets.
Sheesh.