Comment by jdw64
2 days ago
I read the post and roughly summarized it as:
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
> 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.
I agree with some points as well. In fact, the OP argues that sufficient engineering attention can solve the problem, but I think that's only theoretical in reality, it's difficult. It's like C programmers claiming that undefined behavior is manageable.
The "Don't make mistakes" thing isn't even just Programmming, that's why I consider it unforgivable. Railway interlocking starts in the Nineteenth Century. It's a fully mechanical system, if you see an old "Signal box" somewhere, that cabin with a human pulling levers isn't up there just because it's a better vantage point (though that doesn't hurt) it's because there are physically steel cogs and gears meshed together to allow the machine they're operating to only enter safe states. If you make mistakes in that signal box just moving the levers and so on nothing terrible happens. Worst case you annoy people and that's forgiveable.
https://www.youtube.com/watch?v=omYfLDlt-MA
Like Avon says in The Wire, "And how you ain't never gonna be slow? Never be late?". Systems which require that you don't make mistakes will fail.
*Ben
Sorry. Sometimes I can't remember the English spelling. Thanks for the correction. i've fixed it
Ah I was just joking. Same here, non native english speaker, you did well.
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!
We have the potential to get along really well, but this isn't really the right comment thread for that, haha
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.