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.
I don't think Bun actually matters much, even for web development. For sure there is a lot of enthusiasm, but all the production systems I know continue to use Node.js and are not moving to Bun any time soon. In the "real world" not that many people care about it.
I find this sad, as I use Bun as a Node.js replacement that works really well. I wanted improved builds times and run speed. Both things bun provided. It reduced ram usage and worked with the node ecosystem well.
So for some workflows it looked like a flat improvement on all parts.
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
Not accepting a PR because it was purely written by AI is like saying PRs will only be accepted if the developer used a standing desk for more than 75% of the time during the code's creation. In the end, as long as the code is not shit, who cares how the sausage was made!
I find it hard to believe you actually think those two things are similar or equivalent. I've heard many bad analogies in my life but this is so funny that it makes me think you're being sarcastic.
It’s the perfect analogy! People these days complain about AI are complaining about how the sausage was made rather than how the sausage tastes. Prove me wrong
> 2.It felt uncomfortable that they spoke as if Rust prevents things that could actually be handled by Zig's style guide.
"Handled by Zig's style guide" ends up as "Don't make mistakes" which is entirely useless advice. C++ spent years trying to make out that this constitutes useful guidance before gradually accepting that people aren't in fact going to stop making mistakes, you need to provide a better language and tools.
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
I mean I wouldn’t want to work for Andrew Kelley either. Doesn’t mean I don’t see utility in zig. Taking swings at a pretty toxic culture (silicon valley) while refreshing also paints a target on your back. This isn’t unhinged shit though so it hasn’t dissuaded me from learning Zig
And literally 3 sentences later he goes back to insulting him ("productivity fantasy fever dream"). Even if that is true, it's still an unwise post to publish in this form IMHO. If the goal was to defend Zig, that could've been done in a less personal manner.
I think he messed that part up and it comes off as passive aggressive but he is probably scared of the “outrage” from the angels of the internet about how rude he was to Jarred
That is a 100% on point analysis, there was a lot of hype around Bun since the beginning when it was an invite only project. Arguably that same interest is what got Jarred VC funding in the first place.
Note that usage and public interest are not the same quantity, people also care about the potential of a project.
> 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.
I’ve not seen any languages that does not require meticulous care to avoid runtime bugs. Type checking and lifetime ownership eliminate some, but not all of them.
> Type checking and lifetime ownership eliminate some, but not all of them.
They actually remove certain classes completely. E.g. lifetime ownership in Rust removes all bugs related to the reason why it is in the code syntax (a.k.a. lifetime markers remove use-after-free completely in Rust.)
Memory safety problems are still possible in the new Rust Bun:
At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library.
Possible, yes. But it's not like it's terribly difficult to verify correct usage of "unsafe" that amounts to a basic function call to a C library. Trivial uses of unsafe are pretty innocuous.
Yes but through iterative ratcheting, some portion of that unsafe can likely be migrated to idiomatic code without unsafe. And the other 96% of the code now has more mechanical guarantees than it did before.
Static linting in Rust via clippy also makes it pretty straightforward to begin enforcing things like "unsafe blocks need to have safety doc comments" as a CI warning or failure, and there are community tools that focus on this topic too.
I can't stand the practice of "LLM porting" personally but if you're going to do a mechanical rewrite from something else into Rust, this (permit unsafe and unidiomatic but 1:1 translation at first) is a fairly reasonable strategy imo.
People bring this up a lot. What I see here is that thousands of potentially (not actually, just potentially) safety risks have been neatly tagged in the code.
If you took a program written in Zig, Go, C++, or C, you would have no idea which parts of the code were potentially unsafe. Rust makes it clear.
Having them explicitly tagged means they're isolated and can be eradicated over time, if need be. Though in many cases, unsafe blocks are quite safe.
Suppose there's a C library libape which implements monkeys you need in your software. There's a C API where we pass a pointer to a valid monkey and a 32-bit unsigned integer which controls how delicious bananas are. Any 32-bit unsigned integer is valid here, except zero because monkeys always think bananas are at least somewhat delicious, and there's no return value.
Our Rust wrapper probably has Monkey as a type, wrapping one of those valid monkey pointers we mentioned, and so our wrapper for that API call is some unsafe code which just calls the C with this monkey pointer and a non-zero unsigned 32-bit integer which in Rust is just the type NonZeroU32 and we're done. That's a single line, the unsafety checking was all done in Rust's type system, every Monkey has a valid monkey pointer, every NonZeroU32 is (as its name suggests) a non-zero unsigned 32-bit integer.
Now on the other hand, maybe we're wrapping code which takes a char * pointer intended to point at some zero terminated ISO-8859-1 encoded text. That Rust wrapper would be responsible for this translation and maybe you do that work in the wrapper function. But, if you had sixty calls like that, probably you make a Rust type for this problem named like Iso8859dash1Text and then those unsafe calls don't have a lot of boilerplate because all that boilerplate (which is probably even safe Rust depending on how exactly you do it) lives in this Iso8859dash1Text type you made. And that's also a useful model if later you discover the C library lied and it's not ISO-8859-1 it's really Windows Codepage 1252 ...
Yes - I think the proof of the pudding will be whether they put in the effort to eliminate these unsafe blocks. The conversion to Rust is the starting point that makes this possible, but it's definitely not "done" at this point.
If the majority of those are at an FFI boundary to a language without lifetime analysis, I don't really see how they could be fixed without rewriting all that downstream software?
You have to put similar amount of resources when writing in Rust as well. With the difference that it’s more front loaded. Personally I’m a fan of Rust’s approach but the price for having bug free code has to be paid, regardless, one way or the other.
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 Zig code in a way that eliminates not only the current bugs but also prevents similar ones from happening in the future?
I think that post highlights a difference in philosophical approach to software development. Bun is focused on moving fast and will deal with the consequences as they come. Zig takes a more planful approach.
I've experienced both in my career and I fall solidly on the planful side. It's why stopped using homebrew and I've avoided huggingface packages as much as possible.
It is worth noting that before rewriting in Rust, Bun maintained a fork used to accelerate the compilation and informed those who asked that this fork could never be merged due to Zig's zero-LLM policy.
A few weeks later, Bun began the Rust rewrite. Although not explicitly stated, I suspect these two events may be related.
As was mentioned countless times here on HN, the fork didn't get merged not because of any no-AI policy but because the Zig maintainers considered it to be of poor quality and were already working on more comprehensive improvements to the compiler which would bring the same (and more) benefits, but without the downsides and quality issues of the fork.
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.
Jared has behaved appallingly in recent months. Comments about locking out humans from open source code contributions and the gaslighting at the start of the migration are top of mind.
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.
Other people (not meaning this about you) very frequently seem to throw around the BFDL acronym uncritically without remembering or caring that Benevolent is the first word in there.
This blog post is mostly made up of pettiness and is not an isolated incident - he is often pretty "spicy" or downright hostile in comments sections when making an appearance.
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)
Yeah and Andrew Kelley is anti AI for his project because it’s counter to the projects learning goals. I think it’s perfectly fine for a project to determine if AI contributions are accepted. Maybe that means change is slower in that project, maybe that means things are more deliberate too.
OSS projects can survive not being on GitHub, Python was something like 20 years was not on gh. If the service has severe outages and there are alternatives why wouldn’t you move? Most people aren’t contributing to the runtime anyways, they are just using the language.
> 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.
Sounds like the first release is coming very soon.
Given the size of the rewrite I think it's pretty responsible to dogfood it a lot - including with a Claude Code release - before pushing a stable release to the wider community.
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 hardcoe 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.
Your prediction is extremely short sighted, and I can only guess it is because of your extreme pro-AI stance, as well as not being part of the open-source community.
To be honest, I'm also leaning this way, especially because of the hardcore anti-AI stance, so much that Zig will close security vulnerability issues on Codeberg if you mention that they were found with LLMs. I don't think that this is a good approach.
I also think Zig has a rough road ahead, but not because of AI or moving to codeberg. No, it's because Andrew isn't really a BDFL. He's at best a DFL. The project is already mostly closed off to external contributors.
It kind of reminds me of Elm in a way. Though I'm not expecting 6 years of drought just yet.
I have never once in my life cared about where a programming language kept its source and I think if anyone is using that as a basis for decision-making, they are truly a moron.
I agree. It's possible in the future a project hosted on codeberg is a silent "stamp of quality". Though, I still think there could be impact wrt a network effect.
I don't care if it's on GitHub at all, it's not hard to work with any arbitrary git remote. CVS would be a weird choice, but it wouldn't be a dealbreaker on its own. Fossil or some other modern alternative VCS wouldn't be a red flag or weird at all.
But I wasn't talking about contributing to the language, which is a weird standard to use here since Zig isn't interested in outside contributors. I was talking about choosing a programming language for use for some professional or personal project. I don't give a fig what version control solutions the team chooses to use if the language is good and solves my problems, and I would consider it very strange if someone tried to argue that I shouldn't use some language because they put their code on a non-Microsoft owned server.
I generally agree with you that choosing something based on where it's hosted is dumb. I still think there could be an impact wrt a network effect.
The original comment you replied to was talking about "the loss of network effect" and you sounded dismissive of it. It might not even matter, but I think it's somewhat fair to say it could have an impact.
What I assume you mean is not the network effect, where more users of a product makes the product more valuable. That's still true for Zig as more users increase the ecosystem, funding potential etc. regardless of where the compiler source lives.
I think you mean to say something like barrier to entry for contributors? Where having to sign up for a new service will discourage some engagement with the core repo.
One funny thing is that if you go on codeberg and want to submit a PR to Zig, you can't. Because Zig's too big for Codeberg, and you're over your free quota, so you can't push your update to your fork.
Yes there are ways around it if you have patience, but what the heck!!
Worth noting that while it's absolutely unfortunate that we're hitting this Forgejo design flaw, AGit honestly is just a better workflow, and I (Zig core team member here, full push access to the upstream repo) have started using it for pretty much all of my PRs. There are a couple of small things I'd like to see improved about Forgejo's implementation of AGit, but IMO it fundamentally makes so much more sense than the two-step push-then-PR workflow (especially if you're an external contributor who would also need a first step of "fork the repo").
If you bothered to actually learn just a little bit about the Zig project, you'll know that they are doing ok. They never cared about introducing new features at a fast speed, having lots of contributors, or getting corporate sponsorship, if that's not already obvious from the article. In fact, they intentionally stay away from all of that to make the project more sustainable and less prone to the whims of corporations.
Well thats why his prediction is interesting. Hes saying they wont be ok in a couple of years. Of course theyll be there, programming languages dont really die but theyll be a shell of what was once believed to be their potential, a superior replacement for C
Linus attacked bad software, Andrew attacks the Thiel Fellowship, VC Foundings, and AI. There's little or no Linus there, pointing fingers at, and even when he does, he points at code he neither uses nor maintains. Linus don't give a shit about other people projects and businesses.
They don't have a goal of becoming a popular language, though and will continue to work on it as long as there are donations.
They don't care about being mainstream and there are niche companies who appreciate Zig and donate.
Reminds me of another language that I used to know...
For real though, if your goal as a language isn't to become popular then why should anyone learn it? Why should anyone spend their limited time building libraries in it when the language isn't likely to grow (and thus is more likely to disappear)?
> I'm hustling. I'm playing the game. I'm doing what it takes to make this thing mainstream and a viable, practical choice for individuals and companies. If you talk shit about Zig in public, I'm going to fight back. But I respect you. I see you. I understand you. I don't hate you. I would literally buy you a drink.
It's a conflict of core values, and you've demonstrated it here.
You have defined success (for a project, and possibly a person too) as solely 'relevance'.
Jarred would agree with you wholeheartedly, I imagine.
Andrew would ask you to leave.
It's okay to have different values and part ways.
It's not wise, however, to project your personal values onto other people, and judge them on those fabricated merits. You'll end up frustrated and confused more often than not.
Judge their choice of values. Judge them on their alignment with their chosen values.
As an example, Andrew doesn't like Jarred's chosen 'Silicon Valley' values, but thinks that Jarred aligns himself well with those values. This feels as a personal attack to you who also holds those values. And on some level, a person intimating you core values suck couldn't be more personal.
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 an launch towards 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.
"If this was a tweet people would be fine with it"
Actually, some folks do care about how the leader and public face of a project conduct themselves regardless of venue. If a different public figure ie some CEO wrote something reprehensible about some particular ethnic group, is it more excusable or forgivable if they did it on their personal social media account rather than the company blog? Same basic thing.
Public writing in a personal space is still public writing. Being held accountable for publicly stated views is an inherent part of sharing them in public, no?
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.
> 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, and who are not incentivized to go slower. That is a 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 created many programming languages that are just for me). But if a programming language in never adopted then the supposed benefits or improvements of the language never trickle down to us the users of the software, so they just remain interesting ideas (which again is okay).
Andrew kelley runs a tight ship, and his foundation does not need a lot of money to keep going, but he has talked about how working on all the organizational transparency is not his favorite part of the project, and I can see why a lot of young programmers wouldn’t want to go that way.
I agree with some of your points, but I think the Safe C++ project will be difficult because it would require breaking backward compatibility with existing projects. Honestly, I also don't agree with the claim that 'if you manage it well, data races and memory safety errors won't happen.' However, C++ already has so many projects built on it that breaking backward compatibility would cause serious problems. I think it might be better to just switch to a different language altogether.
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.
546 comments
[ 3.3 ms ] story [ 155 ms ] threadSo for some workflows it looked like a flat improvement on all parts.
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
"Handled by Zig's style guide" ends up as "Don't make mistakes" which is entirely useless advice. C++ spent years trying to make out that this constitutes useful guidance before gradually accepting that people aren't in fact going to stop making mistakes, you need to provide a better language and tools.
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?
Note that usage and public interest are not the same quantity, people also care about the potential of a project.
> 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.
They actually remove certain classes completely. E.g. lifetime ownership in Rust removes all bugs related to the reason why it is in the code syntax (a.k.a. lifetime markers remove use-after-free completely in Rust.)
Static linting in Rust via clippy also makes it pretty straightforward to begin enforcing things like "unsafe blocks need to have safety doc comments" as a CI warning or failure, and there are community tools that focus on this topic too.
I can't stand the practice of "LLM porting" personally but if you're going to do a mechanical rewrite from something else into Rust, this (permit unsafe and unidiomatic but 1:1 translation at first) is a fairly reasonable strategy imo.
If you took a program written in Zig, Go, C++, or C, you would have no idea which parts of the code were potentially unsafe. Rust makes it clear.
Having them explicitly tagged means they're isolated and can be eradicated over time, if need be. Though in many cases, unsafe blocks are quite safe.
Don't those blocks need some additional lines for error checking to prevent the unsafety from spreading to the safe code?
Suppose there's a C library libape which implements monkeys you need in your software. There's a C API where we pass a pointer to a valid monkey and a 32-bit unsigned integer which controls how delicious bananas are. Any 32-bit unsigned integer is valid here, except zero because monkeys always think bananas are at least somewhat delicious, and there's no return value.
Our Rust wrapper probably has Monkey as a type, wrapping one of those valid monkey pointers we mentioned, and so our wrapper for that API call is some unsafe code which just calls the C with this monkey pointer and a non-zero unsigned 32-bit integer which in Rust is just the type NonZeroU32 and we're done. That's a single line, the unsafety checking was all done in Rust's type system, every Monkey has a valid monkey pointer, every NonZeroU32 is (as its name suggests) a non-zero unsigned 32-bit integer.
Now on the other hand, maybe we're wrapping code which takes a char * pointer intended to point at some zero terminated ISO-8859-1 encoded text. That Rust wrapper would be responsible for this translation and maybe you do that work in the wrapper function. But, if you had sixty calls like that, probably you make a Rust type for this problem named like Iso8859dash1Text and then those unsafe calls don't have a lot of boilerplate because all that boilerplate (which is probably even safe Rust depending on how exactly you do it) lives in this Iso8859dash1Text type you made. And that's also a useful model if later you discover the C library lied and it's not ISO-8859-1 it's really Windows Codepage 1252 ...
I don't write Rust - but I sure know that I'm not supposed to use 'unsafe'.
For the latter: https://youtu.be/iqddnwKF8HQ?si=cvU8Fh3ah7ZCxg3M
From 26:38
- [0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
I've experienced both in my career and I fall solidly on the planful side. It's why stopped using homebrew and I've avoided huggingface packages as much as possible.
I can imagine Anthropic wanting to acquire Bun without the gimmicks.
A few weeks later, Bun began the Rust rewrite. Although not explicitly stated, I suspect these two events may be related.
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.
This blog post is mostly made up of pettiness and is not an isolated incident - he is often pretty "spicy" or downright hostile in comments sections when making an appearance.
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)
OSS projects can survive not being on GitHub, Python was something like 20 years was not on gh. If the service has severe outages and there are alternatives why wouldn’t you move? Most people aren’t contributing to the runtime anyways, they are just using the language.
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????
> Bun v1.3.14 was the last version of Bun written in Zig. Bun v1.4.0 will be the first version of Bun written in Rust. It's available in canary now.
It's also been shipping with Claude Code since June 17th.
Given the size of the rewrite I think it's pretty responsible to dogfood it a lot - including with a Claude Code release - before pushing a stable release to the wider community.
Anyway, let's try to discuss something more technical: I predict Zig will lose steam, and in 2027, will lose relevance:
1) It's hardcoe 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.
The hypocrisy is puzzling.
It kind of reminds me of Elm in a way. Though I'm not expecting 6 years of drought just yet.
This is absolutely brutal to GitLab
But I wasn't talking about contributing to the language, which is a weird standard to use here since Zig isn't interested in outside contributors. I was talking about choosing a programming language for use for some professional or personal project. I don't give a fig what version control solutions the team chooses to use if the language is good and solves my problems, and I would consider it very strange if someone tried to argue that I shouldn't use some language because they put their code on a non-Microsoft owned server.
The original comment you replied to was talking about "the loss of network effect" and you sounded dismissive of it. It might not even matter, but I think it's somewhat fair to say it could have an impact.
I think you mean to say something like barrier to entry for contributors? Where having to sign up for a new service will discourage some engagement with the core repo.
Yes there are ways around it if you have patience, but what the heck!!
https://forgejo.org/docs/latest/user/agit-support/
"Nvidia, fuck you!"
[0] https://www.youtube.com/watch?v=Q4SWxWIOVBM
Not to mention he was attacking an opaque corporation, not a single person like this blog post does.
If one can easily swap in the next new js engine du jour…
For real though, if your goal as a language isn't to become popular then why should anyone learn it? Why should anyone spend their limited time building libraries in it when the language isn't likely to grow (and thus is more likely to disappear)?
Andrew Kelley - An Open Letter to Everyone I've Butted Heads With (2025 Aug 29) https://andrewkelley.me/post/open-letter-everyone-butted-hea...
You have defined success (for a project, and possibly a person too) as solely 'relevance'.
Jarred would agree with you wholeheartedly, I imagine. Andrew would ask you to leave.
It's okay to have different values and part ways.
It's not wise, however, to project your personal values onto other people, and judge them on those fabricated merits. You'll end up frustrated and confused more often than not.
Judge their choice of values. Judge them on their alignment with their chosen values.
As an example, Andrew doesn't like Jarred's chosen 'Silicon Valley' values, but thinks that Jarred aligns himself well with those values. This feels as a personal attack to you who also holds those values. And on some level, a person intimating you core values suck couldn't be more personal.
I'll note that this is followed by an entirely non-technical statement of opinion.
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.
Eh, Google and ChatGPT both exist?
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.
This post is his personal blog, he is a human writing what he thinks.
If this was a tweet people would be fine with it, but it is a blog so he should make it corporate-y
Actually, some folks do care about how the leader and public face of a project conduct themselves regardless of venue. If a different public figure ie some CEO wrote something reprehensible about some particular ethnic group, is it more excusable or forgivable if they did it on their personal social media account rather than the company blog? Same basic thing.
Public writing in a personal space is still public writing. Being held accountable for publicly stated views is an inherent part of sharing them in public, no?
The contents of his character and thoughts are quite objectionable though.
That's just your opinion though, not an objective fact. I happen to be of the opposite opinion.
> 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, and who are not incentivized to go slower. That is a 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 created many programming languages that are just for me). But if a programming language in never adopted then the supposed benefits or improvements of the language never trickle down to us the users of the software, so they just remain interesting ideas (which again is okay).
Andrew kelley runs a tight ship, and his foundation does not need a lot of money to keep going, but he has talked about how working on all the organizational transparency is not his favorite part of the project, and I can see why a lot of young programmers wouldn’t want to go that way.
> 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