It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake.
I’ve never met Jared or the bun team but I don’t understand all the personal attacks, I just feel the need to correct the facts. Literally who cares what language a JS toolset is written in?
It’s not like they ported JavaScriptCore (the actual JS runtime) to rust even. All that stuff is largely untouched.
>Literally who cares what language a JS toolset is written in?
Maybe you're being coy by asking a rhetorical question you already know the answer to but I'll answer as if you asked sincerely...
There are 2 different groups interacting with software products:
(1) end-users : this is where the "Who cares what language it's written in?!?" is usually applicable. E.g. The finance guys using MS Excel don't care whether it's written in assembly, BASIC, or C Language.
(2) code contributors and/or programming language enthusiasts who see other projects as "validation" of the whatever language they've invested in: these people definitely care.
For all the decades that computer languages have been debated, Group (2) will always discuss projects language choices. E.g. reddit.com switching from Lisp to Python, the Linux kernel fiercely debating future Rust contributions , the Typescript compiler switching from Javascript to Go, Bun switching from Zig to Rust, etc.
People try to lecture others in Group 2 about "don't make a programming language your identity" ... but people are human and they can't look at all the above language choices as totally detached observers. They like to talk about it!
If one is a Zig coder that contributed to the previous Bun Zig codebase, we can't expect them to be neutral observers.
I think you're missing group 3, which is the "assume bad faith and/or bad outcome from any possible change to anything, and especially changes to open source projects that can be interpreted as exogenous, e.g. from an acquirer, and especially if that acquirer is a gigantic commercial entity."
There are not nearly enough disenfranchised Bun-on-Zig contributors to make a dent in this conversation. There are lots of Group 3s in every similar convo, for any combination of technology, project, and acquirer you can name.
> who cares what language a JS toolset is written in?
Anthropic, apparently, not the least because they blanket-closed all issues submitted before the rewrite. If the language were irrelevant, it shouldn’t matter for the existing unfixed issues.
> blanket-closed all issues submitted before the rewrite
You'll need a citation for that. While I'm still not sure whether Claude Code's issue tracker is worth much (Anthropic doesn't seem to engage with individual issues a while lot), it still has 5k+ open issues ranging back to March 2025. Bun also still has all of its Zig-timeline issues, all 5k+ of them. So what's this about?
imagine being the leadership of the one of most valuable US private companies in the world. then you have to make something called a "pull request" that gets "reviewed" by someone named "Jarred" to make improvements to your stuff. do you see how that is untenable?
the language is relevant for political not technical reasons. you could say, blanket closing the Issues, getting rid of this thing called Jarred from your stack, etc., is really an attack on the GitHub and the GitHub Agitator Lifestyles, which is why so many commenters on Hacker News actually care.
> It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
This is even more interesting given that prewar Bun was not a well respected code base. This matters if the code was bad, were the tests bad / not comprehensive as well? If so, the translation to rust whose sole / primary target was test-passing will have a fair amount of undocumented bugs in it.
> poster child for Zig programming language actually being the prime example of How Not To Write Zig Code
> What is the governance structure for Bun by the way? Couldn't find any documents/explanations about how it's supposed to work. I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
And this is a valid question. You are not "defending reality" by refusing to listen to it.
In summary and based solely on my understanding:
- Jared misled people about the intentions of the migration. It's not the worst thing in the world, but it's certainly worthy of criticism.
- Jared has commented before about locking out human contributors from open source projects. Whether he was making a larger point is irrelevant as his comment stands on its own.
- Other Bun contributors, past and future, outside of those employed by Anthropic, did not and likely will not have equal access to the model Jared used for the rewrite.
Jared, working in the public Bun repository, used tooling not available to his community to experiment with a signficant migration. He dismissed all concerns and told people it's just a bit of fun, and that it shouldn't be taken seriously. Most of the controversy would have been avoided were the experiment done in private.
None of this is a big scandal but questions about the project are entirely justified.
Whole classes of bugs WERE fixed by moving to rust. wouldn’t that result in mass closures of classes of bugs that were no longer relevant in rust? What would you prefer?
this whole AI era has put the topic of "do we believe actual reality, or what we hoped/assumed/continue to insist would be reality" front and center. Every discussion is like this these days.
>It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
The rust code is not yet in a stable release, and CC only switched to it in the latest version, so there's not been 60 days of widespread battle testing yet, so i don't see how we could possibly say it will have no negative difference. It hasn't, because nobody is using it yet. It still might.
>Literally who cares what language a JS toolset is written in?
I don't care what language it's in, but i do care how it is written and maintained. I'm not going to trust my projects to a runtime that was written by an LLM in two weeks with practically no human review
Which was completely bonkers -- it happened completely in the open, people were just outraged that something like this happens without asking them and not on a schedule they perceive as adequate. Most of them haven't really grasped what was happening and why. Many still don't.
Rust as a language is irrelevant to this discussion, the problem is that bun was vibe coded by a single dude without any open source community involvement. “bun the open source project” is basically dead at that point: don't expect any of the zig enthusiasts who had their code being forcibly rewritten in a language they don't like to follow Jared.
I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).
"Vibecoded" is not an accurate description of what actually happened. LLMs are extremely good at porting code from one language to another while preserving semantics. Which is why how everything turned out so well was not very surprising.
Rust as a language is not relevant, but the Rust community still helped to popularize the idea that trashing a community by a rewrite is ok if it serves some "higher goal". This rewrite is just a striking example why this is problematic.
Is the idea that a code base reset makes something stop being open source? Or that the number of people doing the reset matters?
I don't see why either of those would be true. The project isn't dead just because it's in a different language now, and for liveness purposes it doesn't matter how it got to that different language.
I think the point is that an “open source project” is more than just the code and license, it’s also the community that builds and maintains it.
A fast rewrite of Bun in Rust has effectively alienated most of the people in the Bun community, so in that sense the “open source project” has died. It’s no longer a community project, it’s just become a personal project again.
I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.
I think the Zig people are really just worried that maybe Zig itself is a DOA language before it has even reached 1.0 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
Zig is a DOA language for other reasons though. The reason why Rust enthusiasts act so morally superior is because they are:
> Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage.
There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. Rust is so thoroughly and obviously the correct thing that using anything less correct should be taken as a sign of engineering incompetence.
If this were true the very small but active community of Zig contributors could just fork it and you could all return to the happy times of not using Bun anyway.
Bun became a thing because it provided some specific benefit to js ecosystem. Zig enabled the rapid development. The people who contributed were definitely helpful but they can still choose to help or not and new people will step up too
> For me this outputs Bun v1.4.0 (macOS arm64). The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version.
Why is that even a thing to object to? You're talking as if you placed stock in the bizarre idea that Anthropic would close source the project and start charging for it.
I wouldn’t use language as strong as OPs but it is against the spirit of FOSS for a corporate owner to use a private prerelease version of their open source software.
I think it’s valid to object to. If 1.4 is good enough to be used by Claude, why not us?
You're running a closed source piece of software (claude code), running on an effectively closed source piece of software (bun), both of them updated daily by AI psychosis bros.
At this point, charging is the least of your issues.
It may be available to us, in the form of a git checkout of their public repository.
It's true that we don't know exactly which, and whether or not there are any other changes added on, but that is the case for every single release of Claude Code that has used bun.
It's probably not. I tried to extract the commit hash from the version of bun packaged in claude code. the commit hashes from previous versions resolve, whereas the commit hash for the current 1.4.0 isn't available.
from strings:
bun-v1.4.0
f6d0fcd24abd48061873c2f1a6fb2a67eee487b8
Upgraded.
Welcome to Bun's latest canary build!
This build does have a different way of identifying itself than earlier builds so it's possible this string isn't correct.
(In contrast, earlier builds that I have locally have commit IDs that can be found in the public repo). I don't think it's particularly damning for them to vendor a canary release, mind you.
> The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version.
> And so, the FOSS project "Bun" silently dies
There’s no implication that it’s because of the switch to Rust.
An interesting tidbit is that large parts of the original Bun source code was a line-by-line port of esbuild from Go to Zig (mentioned here: https://bun.com/blog/bun-in-rust), tbh this lowered my respect for the project a bit (a line-by-line port simply isn't as interesting as original work), and it might also explain the subpar Zig code quality (a line-by-line port from Go to Zig simply won't result in idiomatic Zig). It also might explain why porting from Zig to Rust was done 'on a whim', the actual source code (and the idea of 'original work') never seemed to be all that important to the author (and I wouldn't be surprised if the project does more language-hopping in the future heh).
I read your link, written by Bun's author and totally get his thinking.
In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun.
In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as it helps doing useful things securely.
I don't think the GP had anything to do with the language change itself. More that it marks a clear point of Anthropic taking ownership and governance of the project in a less open direction.
> Why does changing to Rust kill the project? I don't understand the point here.
I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors.
Now, based on comments from this thread, the formerly FLOSS project is somehow granting special access to a corporation that apparently is invested in going way out of their way to push implementations that consume the complete rewrite before the world has access to it.
I for one won't be touching Bun. This doesn't pass the smell test. It feels like a bait-and-switch in progress.
> I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision…
Even if this was a terrible technical decision, it is a good, maybe even unavoidable, business decision. And I don’t think moving to Rust was a bad technical decision at all, given Zig is unstable and constantly changing, and that it’s not memory safe, which is a big problem for something like a JS runtime!
The reason it’s a necessary business decision is that Bun is owned by an AI company and Zig has a policy to not accept AI assisted contributions, making it impossible for Anthropic to contribute to a language that is still evolving rapidly, not to mention the bad marketing of using a language that basically is hostile to your product.
My personal feelings about the matter is that having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim.
I don't care about meh Zig being rewritten to bad Rust if it does the same thing, but taking what is presented as" look at this funny experiment I did" and then taking that into production with barely any announcement is what kills off the interest to me.
Bun has been a great ad for whatever LLM they were using but the cool factor is gone now, and that's really what set it apart from basic NodeJS in my mind.
> taking that into production with barely any announcement is what kills off the interest to me.
Did Bun v1.4.0 release weeks ago and I missed it? I would call a formal release the point that it goes "into production", and I think dogfooding it via Claude Code is yet another form of testing Bun-in-Rust before the latter goes to casual users.
Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
There were very many open pull requests from the community that were all invalidated overnight for something that same community was assured was merely an experiment.
The normal process would be "hey, this experiment is going well, we've made this plan, come help us shake out the new codebase for the switchover in X time." None of that happened. There wasn't even an announcement, just a silent commit that trashed hard work from hundreds of community members.
Developer community. "Open source" historically implied that an interested developer might hack on the code and submit their changes. But if the entire code-base is rewritten by the maintainer every year, then there's no developer community.
It's like a couple of languages I know where there's still one real owner, and there's no real review, and PRs are unlikely to be merged, even with review: They might be open source, but it's more a source visible thing, because you are never going to get a change in, and the language will change directions at the creator's lone whim. The best you can get at times is "I didn't like your PR, so I implemented the feature you tried to add completely different". Typical community killers.
The language an application is authored in does not matter to me, as a user. I care that it is widely-used (safety in numbers), that it works, and that it is fast.
It's cool that the Zig project exists, but I'm unlikely to ever use Zig so that’s sort of orthogonal to my interests.
I don't care about the language, but pre-releases the community don't get access to but released (Anthropic) applications do have access to, feels a bit too on the nose after the acquisition.
Ok, go ask those people what they think then, I feel no outrage over a project switching language or merging whatever. But when once-semi-transparent projects become more opaque after an acquisition, I'm starting to readjust anything to the project I had in mind.
That PR is the rust rewrite. That's some time in the past now. As of this comment, there is no tagged 1.4 release. This is the present. Anthropic is using apparently a version of Bun that is not publicly available. This is orthogonal to it being Rust-based, as all Bun releases now will be.
It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake.
I’ve never met Jared or the bun team but I don’t understand all the personal attacks, I just feel the need to correct the facts. Literally who cares what language a JS toolset is written in?
It’s not like they ported JavaScriptCore (the actual JS runtime) to rust even. All that stuff is largely untouched.
>Literally who cares what language a JS toolset is written in?
Maybe you're being coy by asking a rhetorical question you already know the answer to but I'll answer as if you asked sincerely...
There are 2 different groups interacting with software products:
(1) end-users : this is where the "Who cares what language it's written in?!?" is usually applicable. E.g. The finance guys using MS Excel don't care whether it's written in assembly, BASIC, or C Language.
(2) code contributors and/or programming language enthusiasts who see other projects as "validation" of the whatever language they've invested in: these people definitely care.
For all the decades that computer languages have been debated, Group (2) will always discuss projects language choices. E.g. reddit.com switching from Lisp to Python, the Linux kernel fiercely debating future Rust contributions , the Typescript compiler switching from Javascript to Go, Bun switching from Zig to Rust, etc.
People try to lecture others in Group 2 about "don't make a programming language your identity" ... but people are human and they can't look at all the above language choices as totally detached observers. They like to talk about it!
If one is a Zig coder that contributed to the previous Bun Zig codebase, we can't expect them to be neutral observers.
I think you're missing group 3, which is the "assume bad faith and/or bad outcome from any possible change to anything, and especially changes to open source projects that can be interpreted as exogenous, e.g. from an acquirer, and especially if that acquirer is a gigantic commercial entity."
There are not nearly enough disenfranchised Bun-on-Zig contributors to make a dent in this conversation. There are lots of Group 3s in every similar convo, for any combination of technology, project, and acquirer you can name.
4 replies →
What about Group x.
You just AI generated 1 millions lines of code claiming it's for safety. Who exactly is to make any kind of security guarantees about this?
9 replies →
> who cares what language a JS toolset is written in?
Anthropic, apparently, not the least because they blanket-closed all issues submitted before the rewrite. If the language were irrelevant, it shouldn’t matter for the existing unfixed issues.
> blanket-closed all issues submitted before the rewrite
You'll need a citation for that. While I'm still not sure whether Claude Code's issue tracker is worth much (Anthropic doesn't seem to engage with individual issues a while lot), it still has 5k+ open issues ranging back to March 2025. Bun also still has all of its Zig-timeline issues, all 5k+ of them. So what's this about?
[dead]
imagine being the leadership of the one of most valuable US private companies in the world. then you have to make something called a "pull request" that gets "reviewed" by someone named "Jarred" to make improvements to your stuff. do you see how that is untenable?
the language is relevant for political not technical reasons. you could say, blanket closing the Issues, getting rid of this thing called Jarred from your stack, etc., is really an attack on the GitHub and the GitHub Agitator Lifestyles, which is why so many commenters on Hacker News actually care.
> It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
This is even more interesting given that prewar Bun was not a well respected code base. This matters if the code was bad, were the tests bad / not comprehensive as well? If so, the translation to rust whose sole / primary target was test-passing will have a fair amount of undocumented bugs in it.
> poster child for Zig programming language actually being the prime example of How Not To Write Zig Code
https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
Did he say this opinion before the rewrite, or when he was taking tens of thousands of Bun's money per month?
The crux is:
> What is the governance structure for Bun by the way? Couldn't find any documents/explanations about how it's supposed to work. I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
And this is a valid question. You are not "defending reality" by refusing to listen to it.
In summary and based solely on my understanding:
- Jared misled people about the intentions of the migration. It's not the worst thing in the world, but it's certainly worthy of criticism.
- Jared has commented before about locking out human contributors from open source projects. Whether he was making a larger point is irrelevant as his comment stands on its own.
- Other Bun contributors, past and future, outside of those employed by Anthropic, did not and likely will not have equal access to the model Jared used for the rewrite.
Jared, working in the public Bun repository, used tooling not available to his community to experiment with a signficant migration. He dismissed all concerns and told people it's just a bit of fun, and that it shouldn't be taken seriously. Most of the controversy would have been avoided were the experiment done in private.
None of this is a big scandal but questions about the project are entirely justified.
> I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
Similar to the Claude Code 60s timeout incident [1] it could just be "Jarade decides what gets done and accepted"
[1]: https://news.ycombinator.com/item?id=48949942
Sometimes the questions aren't justified, though, like when someone else’s project is someone else’s project.
It seems like when some folks see “open source” they think the project maintainers owe them something.
An open source MIT license of the source code is very different from being the original copyright holder.
> that this made bun worse in any measurable way
Issues on GitHub was mass closed claiming zig is no longer relevant without fixing the real issues.
Whole classes of bugs WERE fixed by moving to rust. wouldn’t that result in mass closures of classes of bugs that were no longer relevant in rust? What would you prefer?
2 replies →
this whole AI era has put the topic of "do we believe actual reality, or what we hoped/assumed/continue to insist would be reality" front and center. Every discussion is like this these days.
>It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
The rust code is not yet in a stable release, and CC only switched to it in the latest version, so there's not been 60 days of widespread battle testing yet, so i don't see how we could possibly say it will have no negative difference. It hasn't, because nobody is using it yet. It still might.
>Literally who cares what language a JS toolset is written in?
I don't care what language it's in, but i do care how it is written and maintained. I'm not going to trust my projects to a runtime that was written by an LLM in two weeks with practically no human review
The outrage was more how the rewrite was communicated and defended, which was objectively poor.
Which was completely bonkers -- it happened completely in the open, people were just outraged that something like this happens without asking them and not on a schedule they perceive as adequate. Most of them haven't really grasped what was happening and why. Many still don't.
10 replies →
Except that it hasn’t yet hit the real world, the live release is still 1.13.4, the last Zig version. Anthropic does not operate in the real world.
The canary build has been Rust for over a month, available to anyone. In that time it has been used in production for Claude Code and Prisma Compute.
2 replies →
[flagged]
What a load of bs.
> Inevitable collapse
According to who? You? The well ackshually guy?
> Low in trust before acquisition
Cite your sources.
> Unreleased version
v140 is the canary version which has been available for a long time.
https://github.com/oven-sh/bun/releases/tag/canary
> Not open source anymore
Who died and made you the dictator of open source?
Your post is just a bunch of opinions and lies and speculation wrapped as facts.
2 replies →
Rust as a language is irrelevant to this discussion, the problem is that bun was vibe coded by a single dude without any open source community involvement. “bun the open source project” is basically dead at that point: don't expect any of the zig enthusiasts who had their code being forcibly rewritten in a language they don't like to follow Jared.
“bun the JavaScript runtime ” is not dead though.
I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).
"Vibecoded" is not an accurate description of what actually happened. LLMs are extremely good at porting code from one language to another while preserving semantics. Which is why how everything turned out so well was not very surprising.
5 replies →
Rust as a language is not relevant, but the Rust community still helped to popularize the idea that trashing a community by a rewrite is ok if it serves some "higher goal". This rewrite is just a striking example why this is problematic.
Surely a lot of review has happened in the last two months?
10 replies →
> bun was vibe coded by a single dude without any open source community involvement.
I think even this is largely beside the point. The acquisition of any project by Big Capital (whether tech or VC) is usually a killing blow.
Is the idea that a code base reset makes something stop being open source? Or that the number of people doing the reset matters?
I don't see why either of those would be true. The project isn't dead just because it's in a different language now, and for liveness purposes it doesn't matter how it got to that different language.
I think the point is that an “open source project” is more than just the code and license, it’s also the community that builds and maintains it.
A fast rewrite of Bun in Rust has effectively alienated most of the people in the Bun community, so in that sense the “open source project” has died. It’s no longer a community project, it’s just become a personal project again.
2 replies →
That's just like your opinion...? More power to Jared (and anyone else) if they can "vibe code" useful projects like bun.
I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.
I think the Zig people are really just worried that maybe Zig itself is a DOA language before it has even reached 1.0 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
Anyone actually using it knows it is better. The C interop is so good that there is no use-case where C is the better option IMHO
8 replies →
Zig is a DOA language for other reasons though. The reason why Rust enthusiasts act so morally superior is because they are:
> Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage.
https://x.com/typememetics/status/2078572052680790237
There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. Rust is so thoroughly and obviously the correct thing that using anything less correct should be taken as a sign of engineering incompetence.
18 replies →
Bun was the flagship product of zig? In reality or in YC land
If this were true the very small but active community of Zig contributors could just fork it and you could all return to the happy times of not using Bun anyway.
Bun became a thing because it provided some specific benefit to js ecosystem. Zig enabled the rapid development. The people who contributed were definitely helpful but they can still choose to help or not and new people will step up too
> new people will step up too
Or they will not… how could you possibly know.
Emphasis on the FOSS project. The v1.4 mentioned is not (yet?) open source, Claude Code is essentially using a proprietary fork, was GP's point.
You can install it now we with bun upgrade —-canary it something along those lines.
I think you’re missing a word or two.
5 replies →
It's a canary releasing directly from main: https://github.com/oven-sh/bun
We have run it in production for a month: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute
And GP is full of shit as the main branch is the v1.4.0. it is not "released" yet as it is not finished. It is available as canary version.
So Anthropic ships with unfinished version of bun.
Doesn’t sound like responsible software deployment
6 replies →
[flagged]
From the article:
> For me this outputs Bun v1.4.0 (macOS arm64). The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version.
Which is still true as I write this comment.
6 replies →
Bun is now mainly the runtime for claude code. All changes will go in to make claude code better.
It's not about making the dev experience better than node, that use-case is now secondary.
As an open source - community driven project? Have you looked at the repo on github?
Theres thousands of PRs from claude agents or whatever.
Yeah really feels like a worthwhile place to contribute lol.
> As an open source - community driven project? Have you looked at the repo on github?
FOSS as in FOSS - Free and Open Source Software. Has nothing to do with if it's community driven or not, I'm strictly talking about FOSS.
The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us. We don’t know what’s actually in it.
Why is that even a thing to object to? You're talking as if you placed stock in the bizarre idea that Anthropic would close source the project and start charging for it.
Stay your pitchforks.
I wouldn’t use language as strong as OPs but it is against the spirit of FOSS for a corporate owner to use a private prerelease version of their open source software.
I think it’s valid to object to. If 1.4 is good enough to be used by Claude, why not us?
10 replies →
You're running a closed source piece of software (claude code), running on an effectively closed source piece of software (bun), both of them updated daily by AI psychosis bros.
At this point, charging is the least of your issues.
It may be available to us, in the form of a git checkout of their public repository.
It's true that we don't know exactly which, and whether or not there are any other changes added on, but that is the case for every single release of Claude Code that has used bun.
It's probably not. I tried to extract the commit hash from the version of bun packaged in claude code. the commit hashes from previous versions resolve, whereas the commit hash for the current 1.4.0 isn't available.
from strings:
This build does have a different way of identifying itself than earlier builds so it's possible this string isn't correct.
(In contrast, earlier builds that I have locally have commit IDs that can be found in the public repo). I don't think it's particularly damning for them to vendor a canary release, mind you.
That is also true of the rest of their codebase, no?
Moving the goalposts?
No? I think OP’s comment was very clear:
> The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version.
> And so, the FOSS project "Bun" silently dies
There’s no implication that it’s because of the switch to Rust.
17 replies →
Yeah same, according to one of the Zig team members, the original source code wasn't all that anyway.
But this is HN, a subsection of which places a high importance on what language something is written in, moreso than what it does (feels like).
An interesting tidbit is that large parts of the original Bun source code was a line-by-line port of esbuild from Go to Zig (mentioned here: https://bun.com/blog/bun-in-rust), tbh this lowered my respect for the project a bit (a line-by-line port simply isn't as interesting as original work), and it might also explain the subpar Zig code quality (a line-by-line port from Go to Zig simply won't result in idiomatic Zig). It also might explain why porting from Zig to Rust was done 'on a whim', the actual source code (and the idea of 'original work') never seemed to be all that important to the author (and I wouldn't be surprised if the project does more language-hopping in the future heh).
I read your link, written by Bun's author and totally get his thinking.
In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun.
In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as it helps doing useful things securely.
2 replies →
I don't think the GP had anything to do with the language change itself. More that it marks a clear point of Anthropic taking ownership and governance of the project in a less open direction.
Definitely, it was a possible reason why Zig actually matters in the industry.
Now it is a Deno clone, both without anything enticing over node.js.
> Why does changing to Rust kill the project? I don't understand the point here.
I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors.
Now, based on comments from this thread, the formerly FLOSS project is somehow granting special access to a corporation that apparently is invested in going way out of their way to push implementations that consume the complete rewrite before the world has access to it.
I for one won't be touching Bun. This doesn't pass the smell test. It feels like a bait-and-switch in progress.
> I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision…
Even if this was a terrible technical decision, it is a good, maybe even unavoidable, business decision. And I don’t think moving to Rust was a bad technical decision at all, given Zig is unstable and constantly changing, and that it’s not memory safe, which is a big problem for something like a JS runtime!
The reason it’s a necessary business decision is that Bun is owned by an AI company and Zig has a policy to not accept AI assisted contributions, making it impossible for Anthropic to contribute to a language that is still evolving rapidly, not to mention the bad marketing of using a language that basically is hostile to your product.
A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts. That somehow kills the project. ok!
> A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts.
No,not really. There is only one point: does Bun acknowledge that past contributors still hold copyright over the Rust rewrite?
1 reply →
of course they also gave away their own claim to be the copyright owner, but that's neither here nor there ; )
I didn't read OP as complaining about the rewrite, but about the (lack of clear) governance after being acquired by Anthropic.
My personal feelings about the matter is that having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim.
I don't care about meh Zig being rewritten to bad Rust if it does the same thing, but taking what is presented as" look at this funny experiment I did" and then taking that into production with barely any announcement is what kills off the interest to me.
Bun has been a great ad for whatever LLM they were using but the cool factor is gone now, and that's really what set it apart from basic NodeJS in my mind.
> taking that into production with barely any announcement is what kills off the interest to me.
Did Bun v1.4.0 release weeks ago and I missed it? I would call a formal release the point that it goes "into production", and I think dogfooding it via Claude Code is yet another form of testing Bun-in-Rust before the latter goes to casual users.
Claude code isn't used by casual users?
Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
There were very many open pull requests from the community that were all invalidated overnight for something that same community was assured was merely an experiment.
The normal process would be "hey, this experiment is going well, we've made this plan, come help us shake out the new codebase for the switchover in X time." None of that happened. There wasn't even an announcement, just a silent commit that trashed hard work from hundreds of community members.
9 replies →
Developer community. "Open source" historically implied that an interested developer might hack on the code and submit their changes. But if the entire code-base is rewritten by the maintainer every year, then there's no developer community.
It's like a couple of languages I know where there's still one real owner, and there's no real review, and PRs are unlikely to be merged, even with review: They might be open source, but it's more a source visible thing, because you are never going to get a change in, and the language will change directions at the creator's lone whim. The best you can get at times is "I didn't like your PR, so I implemented the feature you tried to add completely different". Typical community killers.
The language an application is authored in does not matter to me, as a user. I care that it is widely-used (safety in numbers), that it works, and that it is fast.
It's cool that the Zig project exists, but I'm unlikely to ever use Zig so that’s sort of orthogonal to my interests.
I don't care about the language, but pre-releases the community don't get access to but released (Anthropic) applications do have access to, feels a bit too on the nose after the acquisition.
The whole point of the outrage was that 1.4 was merged into main. Publicly. So I’m not sure what you mean.
Everything is in the open: PR #30412
> The whole point of the outrage
Ok, go ask those people what they think then, I feel no outrage over a project switching language or merging whatever. But when once-semi-transparent projects become more opaque after an acquisition, I'm starting to readjust anything to the project I had in mind.
That PR is the rust rewrite. That's some time in the past now. As of this comment, there is no tagged 1.4 release. This is the present. Anthropic is using apparently a version of Bun that is not publicly available. This is orthogonal to it being Rust-based, as all Bun releases now will be.
7 replies →