Live data from Hacker News

My thoughts on the Bun Rust rewrite

andrewkelley.me

61–70 of 757 posts

Re: My thoughts on the Bun Rust rewrite

#62
post #48

Earlier quoted context omitted.

Can you criticize a project which is mainly contributed and managed by one person without criticizing the same person who does the decisions that cause criticisms?

Yes, I think very easily and I have read examples of this. There are bits of this in the article, but the main thrust attempt to portray Jarred as a greedy asshole enamored with Thiel/VC thought is not about the project and quite clear reading the article. It’s entirely tactless and bitter imo

> main thrust attempt to portray Jarred as a greedy asshole enamored with Thiel/VC thought

What made you get that takeaway from the article? I didn't get that feeling at all, mainly seems to be something like "Jarred does some good and some bad, personally I don't agree, still wish him well", but clearly some specific part in the article must have given you this impression, if so what part?

Re: My thoughts on the Bun Rust rewrite

#63
post #49
post #30

Earlier quoted context omitted.

Same. After following the drama on HN and Twitter it's pretty clear Jarred has been intentionally doing something that's hurting Zig/Bun community. What I've seen check out with those statements in the post

To me, most on HN have drank the AI koolaid (and/or are financially invested in it), and God forbid a direct and personal critique on a project owned by Anthropic! We must not let the shareholder value fall /s

You only need to follow Jarred/Bun's own comments on Twitter/HN to figure things out, where selective info were posted based on some agenda instead of clearing things up, aka communication

Re: My thoughts on the Bun Rust rewrite

#64
post #14

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?

Static guarantees are better than stochastic parrots. A static linger beats telling Claude "check this idiom". Etc etc.

Re: My thoughts on the Bun Rust rewrite

#66
post #45
post #42

Earlier quoted context omitted.

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.

Yes that's true, I'm biased because I am pro-AI. What are your hopes and predictions for the Zig project?

I do hope they keep their stance and philosophy though it is not the easiest with a BDFL governance. I do not have predictions though, it seems silly to try and do so when it will be a random chance outcome

Re: My thoughts on the Bun Rust rewrite

#67

> The main problem, however, was code quality. > 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 r…

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.

So less meticulous care then?

Re: My thoughts on the Bun Rust rewrite

#68
post #50

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. This article puts me off learning Zig.

> Would have been a great opportunity to outline the benefits of Zig!

Eh, Google and ChatGPT both exist?

Re: My thoughts on the Bun Rust rewrite

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

Re: My thoughts on the Bun Rust rewrite

#70
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 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).

> This attention could have been harnessed in a few different ways. For example, he could have easily achieved a solid living via crowdfunding, even for San Francisco standards.

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.

Now let me be clear I actually like Zig, and have promoted it on Hacker News before, and written some code myself. I actual uses Zigcc in one of my projects because it makes my life easier. I genuinely love the tooling of Zig, and I feel like the language respects my time. I want the language to succeed

I also think that Andrew Kelley is a principled man with good engineering sense, and has turned down opportunities that would have made him a lot more money, were he to violate his own principles. That is admirable, and he has demonstrated it on so many occasions that it is currently not a question to me. What I would like to see, and what Andrew has said Zig focuses is how Zig can improve program correctness even more, without requiring me, or my coworkers to be a 10x programmer

1. https://youtu.be/U46fJ2bJ-co?t=2780

Post reply on HN