I was wrong to be upset this whole time that the rewrite would hurt Zig. This is one of those rare occasions when I’m glad I was wrong. Interesting insights.
1.It felt uncomfortable that Bun was presented as a representative example of Zig. From the internal Zig perspective, it looked more like a bad example of how to use Zig.
2.It felt uncomfortable that they spoke as if Rust prevents things that could actually be handled by Zig's style guide.
3.I(OP,andrewkelly) don't think badly of Jarred as a person, but after signing a contract with VC, the management side has been poor.
4.The Bun documentation looked like marketing.
5.Bad contributions driven by AI came through indirect promotion of Bun, which attracted interest from people after it was acquired by Antropic.
I understand that it's burdensome to see Bun as Zig's representative success story, and I get the wish not to see Rust rewrites through a lens of language superiority. But on the flip side, I'm not sure I would have ever learned about Zig if not for Bun.
While the criticism is valid, I also understand Bun's position. After all, Antropic's acquisition of Bun was ultimately about showing that even a 'new language' can be used effectively with AI, and that's precisely where the friction arose.
I think the refusal to accept AI from a purely human programmer perspective is a matter of personal values, and I find the Zig team admirable on a human level. (Though I'm an active proponent of AI, so my view differs.)
Both sides have valid points, but sometimes I wish someone would turn the emotional and political dynamics of open source into a novel. I think it would be fascinating
It feels like the first half of blog post is less of "thoughts on the Bun Rust Rewrite" and more "I don't like Jarred, he's a bad programmer and manager".
Maybe I'm wrong, but it strongly feels this way. I'm not saying that Andrew is right or wrong, it's just that you could throw out most of the first half of the post and not lose anything actually on topic.
> But having graduated from the Thiel Fellowship school of thought rather than university, he was essentially groomed from a young age into uncritically embracing the Silicon Valley mindset, and he took venture capital.
> Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective.
> Jarred was already writing slop well before he had access to LLMs
"Crowdfunding" here likely means a bit differently than gofundme style projects - it is not $1-2 monthly contributions from individual developers donating from their personal money. It would be quite impossible to fund any kind of salary with that as you imagine.
It is closer to corporate sponsorships, plenty of projects[1] can pull in few hundred thousand a year.
The post itself talks about a $5k/month donation from Bun to Zig Foundation. ZSF generates about a half million in donations https://ziglang.org/news/2025-financials/
The "crowdfunding" term is here to contrast direct VC funding (that Bun took) from a single source to more diffuse(albeit smaller) funding that ZSF style projects operate under. Without VC funding Bun wouldn't need to , and if non profit 501(x) then simply not even be to consider an acquisition from Anthropic.
Of course Zig (and other projects) benefit from indirect VC funding too - Bun could only afford to donate $5k/ month on Zig because they took VC money after all.
We can always keep going down this secondary/tertiary effects for any tech funding it would unavoidable even with direct small donations - people who contribute are likely drawing salary from VC funded companies, and would contribute less if market goes south and funding plus jobs dry up. . The idea being the level of influence from corporate goal pressure reduces with degrees of separation.
There is a good amount history of this model. Linus Torvalds work itself is by funded by Linux Foundation through a fellowship. LSF charges $500,000 from their 12 Platinum members that includes Microsoft. Nvidia is a silver member, he has famously used some colorful language against both in the past, which in theory would be lot more difficult without the diffuse structure LSF generates funding ( compared to direct employment/VC funding).
[1]That isn't to say that a lot of core projects the entire internet economy depends on is maintained by one guy in Nebraska voluntarily without any support.
> The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it.
Perhaps the amount of bugs comes from using a C-like language that requires meticulous manual care to avoid writing runtime bugs.
Even C++ would be a safer choice because of RAII.
When you have to dedicate significant resources to avoid/fix runtime issues that are made impossible at compile time by other languages, the programmer isn't entirely at fault.
To me, this whole effort of rewriting Bun from Zig to Rust looks like a big marketing move. The question is: if Anthropic AI is really that powerful, why not just fix the bugs and give it the more ambitious task of redesigning the existing Bun Zig codebase in a way that eliminates not only the current bugs but also prevents similar ones from happening in the future?
I for one appreciate a public figure with a wildly opposed mindset to the Silicon Valley/VC-Funded/Ultrascaling/whatever crowd.
The pushback is warranted and on point, especially the technical points. It has taken a suspicious amount of time to produce the fabled blog post which I don't think states almost any new information beyond what Jarred has already shared on twitter. The one (and very interesting) exception is the theoretical price of the rewrite via the API pricing.
Zig is getting that Elm, etc vibe. Genius/visionary BFDL who's also personally incapable of leading the project towards healthy long-term viability.
Say what you will about Matz or José Valim, I don't think they'd ever write a "and don't let the door hit you on the way out" screed full of personal attacks ("stinky manager", "writing slop", "a total shit show") against a person who led a very prominent project and financially supported the language.
well, for me personally, "the" Zig project is not Bun but Ghostty, and it always has been.
yeah, Mitchell is very pro-AI, but he is thoughtful, and he sometimes highlights the difference between Zig's and Ghostty's approaches to LLMs (outright ban vs taming)
> So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.
Seen this time and time again, project/organization gets taken over, and everything "good" they did doesn't get exited with fanfare or anything, just silently dropped as your benefactor starts silently ignoring you.
I'm really happy they saw the writing on the all and were prepared for the inevitable, a really great lesson you shouldn't need to learn yourself the hard way, and FOSS project relying on one/two big donators should take heed, we'll see a lot more of this in the developer tooling ecosystem moving forward for sure.
Despite stated otherwise in the post, this is a personal attack.
Anyway, let's try to discuss something more technical: I predict Zig will lose steam, and in 2027, will lose relevance:
1) It's hardcore Anti-AI
2) It's moved to Codeberg
3) It doesn't have the momentum to sustain the disadvantages of these two decisions
The project will in max 2 years make a blog post, not admitting to their mistakes, telling themselves that Zig is a success, despite the industry having moved on.
Not every project needs "steam", "momentum", and "moving with the industry". This is the Silicon Valley mentality post is talking about. All of this is VC versus hackers. One side only cares about productivity and profits, other only cares about technical elegance and perfection.
It's hard, in my opinion, to lend credence to the author here when they decided to devote the first and largest section of their article to an incisive display of speculative ad hominem.
Would have been a great opportunity to outline the benefits of Zig! I've been keen to pick Zig up recently due to mitchellh's evangelism and inspiring writing on the subject.
I notice something more interesting. This post shows Andrew to not only personally criticise Ben but also clearly shows an ideological stance against AI. I can see it from multiple angles - refusing AI PR's, refusing Anthropic's donation and multiple other things.
Either this ideology helps Zig position itself as a hand crafted language. Or this ideology is self defeating.
I'm glad LLM coding exists for people who want to move at an insane superhuman speed (perhaps they're trying to achieve escape velocity and launch into the stars or something) so that they don't grind down their fellow humans.
You can either do local optimization - a single individual moving as fast and as hard as humanly possible, or global optimization - a team working together and amplifying each other's efforts to produce something that is greater than the sum of its parts.
While I understand ZSF's bittersweet relationship with Oven and agree to several points (especially preparedness), this writing is badly structured and that shows something. Hope to see him turning around.
I found this post very refreshing! I’m sure it would have been very tempting to one-up the “PR-speak” of the Bun post. Likewise, it would have been very tempting to include the same set of facts that reflect negatively on Jarred, while studiously concealing one’s own opinion (eg “I heard people called him a stinky manager. I am not saying that, other people are, but I’m not”). I appreciated that it was just … genuine.
While I agree that the Zig code in Bun could be better, and that the Silicon Valley pressure to move fast and break things prevented a lot of suggested improvements, this feels like the same argument as people who write C or C++ where people think they wouldn’t make mistakes.
For example this section
> We've been trying to warn you about your comptime abuse for years.
You could replace comptime with templates in C++ and it would be the same story. People will abuse features you put in the language. Is C++ a good language that people are just using wrong? According to Bjarne Stroustrup yes, and the C++ core guidelines fixes those issues, but a lot of people seem to disagree. Don't believe me here is an interview where he talks about memory safety in C++? ^1
> Ryan: One thing that I think C++ is uh infamous for is kind of like memory safety issues or kind of foot guns that exist there.
> Bjarne: I'm so tired of that. Um I haven't had those problems for years. Um, and somebody did a a study of the obvious problems with buffer overflows and um people hacking in using that kind of stuff and uh almost all of the uh these cases when people writing C style code or in C and uh Herb Server has a a talk with with actual numbers and they they are quite significant. It's it's sort of that kind of problems more than 90% are for people that don't write modern C++. They they use raw pointers to pass things around without um the number of elements. No fat pointers, no spans. um you you have them in C++. You can use them. You can use uh vectors. We have hardened libraries. Everybody has hardened libraries that that does the runtime checking. Uh Apple has it. Google has it. Microsoft has it. It's just not standard till now. C++ 26 has a hardened option that are standard. uh and the work I'm doing on profiles will give you a way of guaranteeing that you don't do the stupid things. Um so anyway, uh fundamentally theoretically the problem was solved many years ago and people just do what they've always done and get the problems they've always had. And uh that makes me sad and uh it's one of the things that makes me work on uh coding guidelines and on enforced profiles and on education. I mean education is one way to solve the problem. Is there a way to get the compiler to just prevent people from doing all those risky things? And is that enabled by default in modern C++ today? No, but it should be. I'm proposing that for C++ 29. Uh the simpler versions of that should have been in in in uh C++ 26, but there are still a lot of people even in the C++ standards committee that are very devoted to uh their old code and their old ways of doing things. Um there's people who says you should only standardize what is common in industry. But when the bugs are common in industry, you should do something else.
Is this going to be Zig's answers to real issues that people have in the real world? I'd argue that's not good enough for a modern systems programming language.
> We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt.
The vast majority of software is written by businesses, who have to cater to the lowest common denominator in their code base, including slop programmers, pre or post llm. They are not incentivized to go slower. We will never see a mass adoption of Tiger Style programming (though I would be happy to be proven wrong). That is the reality of what we need programming languages to help with in 2026. I've never met a professional programmer that has not seen or said the same thing about a code base that they've worked on.
New programming languages need to contend with that reality if they want to be adopted en masse. If not they are doomed to not be adopted (which is okay I've ...
This is quite an interesting read from Andrew's perspective. But one line tells me everything I needed to know.
> The blog post is expertly written. It's almost like the marketing department of a trillion dollar company has a lot of money riding on this article.
Even Andrew knew that this was going to be Anthropic's marketing opportunity for AI to rewrite Bun from Zig into Rust. This post from Jarred says it all. [0] If you have access to hundreds of billions worth of resources (infinite tokens and compute), they don't care what others think and some relationships are just cheap to discard.
Like I said before in [1] and [2], Bun (now Anthropic) does not care about you. They did this to market the capabilities of their AI models and this rewrite was an example of that in broad daylight. Even if Zig allowed AI generated contributions, this move was going to happen anyway.
I cannot believe that many commenters in [0] at the time did not see that this rewrite was eventually going to happen.
142 comments
[ 2.3 ms ] story [ 104 ms ] thread1.It felt uncomfortable that Bun was presented as a representative example of Zig. From the internal Zig perspective, it looked more like a bad example of how to use Zig.
2.It felt uncomfortable that they spoke as if Rust prevents things that could actually be handled by Zig's style guide.
3.I(OP,andrewkelly) don't think badly of Jarred as a person, but after signing a contract with VC, the management side has been poor.
4.The Bun documentation looked like marketing.
5.Bad contributions driven by AI came through indirect promotion of Bun, which attracted interest from people after it was acquired by Antropic.
I understand that it's burdensome to see Bun as Zig's representative success story, and I get the wish not to see Rust rewrites through a lens of language superiority. But on the flip side, I'm not sure I would have ever learned about Zig if not for Bun.
While the criticism is valid, I also understand Bun's position. After all, Antropic's acquisition of Bun was ultimately about showing that even a 'new language' can be used effectively with AI, and that's precisely where the friction arose.
I think the refusal to accept AI from a purely human programmer perspective is a matter of personal values, and I find the Zig team admirable on a human level. (Though I'm an active proponent of AI, so my view differs.)
Both sides have valid points, but sometimes I wish someone would turn the emotional and political dynamics of open source into a novel. I think it would be fascinating
Maybe I'm wrong, but it strongly feels this way. I'm not saying that Andrew is right or wrong, it's just that you could throw out most of the first half of the post and not lose anything actually on topic.
> But having graduated from the Thiel Fellowship school of thought rather than university, he was essentially groomed from a young age into uncritically embracing the Silicon Valley mindset, and he took venture capital.
> Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective.
> Jarred was already writing slop well before he had access to LLMs
The whole post felt like a personal criticism of Jarred.
That sounds completely surreal. Is Bun really used that much?
It is closer to corporate sponsorships, plenty of projects[1] can pull in few hundred thousand a year.
The post itself talks about a $5k/month donation from Bun to Zig Foundation. ZSF generates about a half million in donations https://ziglang.org/news/2025-financials/
The "crowdfunding" term is here to contrast direct VC funding (that Bun took) from a single source to more diffuse(albeit smaller) funding that ZSF style projects operate under. Without VC funding Bun wouldn't need to , and if non profit 501(x) then simply not even be to consider an acquisition from Anthropic.
Of course Zig (and other projects) benefit from indirect VC funding too - Bun could only afford to donate $5k/ month on Zig because they took VC money after all.
We can always keep going down this secondary/tertiary effects for any tech funding it would unavoidable even with direct small donations - people who contribute are likely drawing salary from VC funded companies, and would contribute less if market goes south and funding plus jobs dry up. . The idea being the level of influence from corporate goal pressure reduces with degrees of separation.
There is a good amount history of this model. Linus Torvalds work itself is by funded by Linux Foundation through a fellowship. LSF charges $500,000 from their 12 Platinum members that includes Microsoft. Nvidia is a silver member, he has famously used some colorful language against both in the past, which in theory would be lot more difficult without the diffuse structure LSF generates funding ( compared to direct employment/VC funding).
[1]That isn't to say that a lot of core projects the entire internet economy depends on is maintained by one guy in Nebraska voluntarily without any support.
> The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it.
Perhaps the amount of bugs comes from using a C-like language that requires meticulous manual care to avoid writing runtime bugs.
Even C++ would be a safer choice because of RAII.
When you have to dedicate significant resources to avoid/fix runtime issues that are made impossible at compile time by other languages, the programmer isn't entirely at fault.
Not sure which is worse.
The pushback is warranted and on point, especially the technical points. It has taken a suspicious amount of time to produce the fabled blog post which I don't think states almost any new information beyond what Jarred has already shared on twitter. The one (and very interesting) exception is the theoretical price of the rewrite via the API pricing.
Say what you will about Matz or José Valim, I don't think they'd ever write a "and don't let the door hit you on the way out" screed full of personal attacks ("stinky manager", "writing slop", "a total shit show") against a person who led a very prominent project and financially supported the language.
yeah, Mitchell is very pro-AI, but he is thoughtful, and he sometimes highlights the difference between Zig's and Ghostty's approaches to LLMs (outright ban vs taming)
Seen this time and time again, project/organization gets taken over, and everything "good" they did doesn't get exited with fanfare or anything, just silently dropped as your benefactor starts silently ignoring you.
I'm really happy they saw the writing on the all and were prepared for the inevitable, a really great lesson you shouldn't need to learn yourself the hard way, and FOSS project relying on one/two big donators should take heed, we'll see a lot more of this in the developer tooling ecosystem moving forward for sure.
It doesn't look done.
And it looks like work on the rewrite began in early may: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
So... its more like a 2 month rewrite that is definitely not done yet????
Anyway, let's try to discuss something more technical: I predict Zig will lose steam, and in 2027, will lose relevance:
1) It's hardcore Anti-AI 2) It's moved to Codeberg 3) It doesn't have the momentum to sustain the disadvantages of these two decisions
The project will in max 2 years make a blog post, not admitting to their mistakes, telling themselves that Zig is a success, despite the industry having moved on.
Would have been a great opportunity to outline the benefits of Zig! I've been keen to pick Zig up recently due to mitchellh's evangelism and inspiring writing on the subject.
This article puts me off learning Zig.
Either this ideology helps Zig position itself as a hand crafted language. Or this ideology is self defeating.
You can either do local optimization - a single individual moving as fast and as hard as humanly possible, or global optimization - a team working together and amplifying each other's efforts to produce something that is greater than the sum of its parts.
the tech industry's fake politeness has caused pain and confusion.
& yeah - I had already stayed off Bun before the whole rewrite, but now more reasons.
For example this section
> We've been trying to warn you about your comptime abuse for years.
You could replace comptime with templates in C++ and it would be the same story. People will abuse features you put in the language. Is C++ a good language that people are just using wrong? According to Bjarne Stroustrup yes, and the C++ core guidelines fixes those issues, but a lot of people seem to disagree. Don't believe me here is an interview where he talks about memory safety in C++? ^1
> Ryan: One thing that I think C++ is uh infamous for is kind of like memory safety issues or kind of foot guns that exist there.
> Bjarne: I'm so tired of that. Um I haven't had those problems for years. Um, and somebody did a a study of the obvious problems with buffer overflows and um people hacking in using that kind of stuff and uh almost all of the uh these cases when people writing C style code or in C and uh Herb Server has a a talk with with actual numbers and they they are quite significant. It's it's sort of that kind of problems more than 90% are for people that don't write modern C++. They they use raw pointers to pass things around without um the number of elements. No fat pointers, no spans. um you you have them in C++. You can use them. You can use uh vectors. We have hardened libraries. Everybody has hardened libraries that that does the runtime checking. Uh Apple has it. Google has it. Microsoft has it. It's just not standard till now. C++ 26 has a hardened option that are standard. uh and the work I'm doing on profiles will give you a way of guaranteeing that you don't do the stupid things. Um so anyway, uh fundamentally theoretically the problem was solved many years ago and people just do what they've always done and get the problems they've always had. And uh that makes me sad and uh it's one of the things that makes me work on uh coding guidelines and on enforced profiles and on education. I mean education is one way to solve the problem. Is there a way to get the compiler to just prevent people from doing all those risky things? And is that enabled by default in modern C++ today? No, but it should be. I'm proposing that for C++ 29. Uh the simpler versions of that should have been in in in uh C++ 26, but there are still a lot of people even in the C++ standards committee that are very devoted to uh their old code and their old ways of doing things. Um there's people who says you should only standardize what is common in industry. But when the bugs are common in industry, you should do something else.
Is this going to be Zig's answers to real issues that people have in the real world? I'd argue that's not good enough for a modern systems programming language.
> We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt.
The vast majority of software is written by businesses, who have to cater to the lowest common denominator in their code base, including slop programmers, pre or post llm. They are not incentivized to go slower. We will never see a mass adoption of Tiger Style programming (though I would be happy to be proven wrong). That is the reality of what we need programming languages to help with in 2026. I've never met a professional programmer that has not seen or said the same thing about a code base that they've worked on.
New programming languages need to contend with that reality if they want to be adopted en masse. If not they are doomed to not be adopted (which is okay I've ...
> The blog post is expertly written. It's almost like the marketing department of a trillion dollar company has a lot of money riding on this article.
Even Andrew knew that this was going to be Anthropic's marketing opportunity for AI to rewrite Bun from Zig into Rust. This post from Jarred says it all. [0] If you have access to hundreds of billions worth of resources (infinite tokens and compute), they don't care what others think and some relationships are just cheap to discard.
Like I said before in [1] and [2], Bun (now Anthropic) does not care about you. They did this to market the capabilities of their AI models and this rewrite was an example of that in broad daylight. Even if Zig allowed AI generated contributions, this move was going to happen anyway.
I cannot believe that many commenters in [0] at the time did not see that this rewrite was eventually going to happen.
[0] https://news.ycombinator.com/item?id=48019226
[1] https://news.ycombinator.com/item?id=48240829
[2] https://news.ycombinator.com/item?id=48073893