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.

That’s quite a statement to make at the end of a post that seems to contain little else…all just thinly veiled.

Saying someone has „beginner energy“ but reframing it as a faux positive (this person fails and thus learns)

Or saying the grapevine says someone is a „stinky manager“? Basically I’m not saying this person is bad it’s just that I need to bring up on this blog that everyone agrees this person is bad.

All seems to be in very poor taste even if true…

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.

> 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.

Interesting I wonder if its something Jarred did locally or something else that was just not widely done by the whole team? I dont like to make bad assumptions about devs or dev teams without first asking. I owe credit to HN for one of the guidelines which states something like do not assume intentional malice in comments, I feel like we assume the worst in general about other devs, but people are imperfect and make mistakes.

That said as others noted this post could have been written a bit differently while still pointing out genuine issues. The ad hominem attacks are a bit unnecessary and add nothing of value to what could have been a better response.

The whole post felt like a personal criticism of Jarred.

I know very little about Jared but his article yesterday, which I read, seemed appreciative of Zig. I now learn he's donated significant chunks of money to them.

This entire article is publicly and personally attacking him for choosing a different product.

It's insane to me that Andrew thinks this post will somehow exonerate Zig when it really just makes them look childish. Or maybe he doesn't care, and just wants to attack Jarred?

The other (very salient) points notwithstanding, I'm afraid this quote shows that Zig hasn't learned a lesson that other languages of its generation (and older) have: if a project's memory safety depends only on "responsible engineering practices", then that project most likely won't be memory safe. Quoting the "swiss cheese" model used in risk management: one slice of cheese (engineering practices) just isn't enough if you want to be reasonably sure your program is memory safe.

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.

I'm rooting for Zig either way, even though I have nothing against Rust and I don't directly use bun.

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.

I was on a platform team and I had a constant backlog of bugs (introduced by others) that I was working on and the two most impactful things for preventing bugs were Typescript and Cypress (playwright-like testing before playwright).

I've dealt with many shitty code bases and the only way that worked for removing bugs was automation. It didn't matter how many bodies you threw at the problem.

> Then why are you saying you have so many annoying bugs in the Zig code? What happened to the test suite being sufficient to catch everything?

You can't use tests for trying to catch use after frees and other memory bugs for the same reason you can't use unit tests as a replacement for type checking, the combinatorial explosion of possible inputs into functions makes unit testing types across an entire project impossible.

Anyway, Jared donated $60k a month to this project and tried to resolve this in the most diplomatic way possible and still got personally attacked. The lesson from this article is don't donate to the Zig project because if you migrate away from it they will try to ruin your reputation.

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)

The points seem valid, however, and I will likely steer clear of Bun.

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.

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.

> 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. 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 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.

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