In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage.
But more significantly, in the medium term it looks likely that AI coding is going to overtake the industry before Zig gets properly established. And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code - why open yourself up to memory unsafety on top of everything else? Further, the Zig community appears to value a hand-crafted, 'artisanal' approach to software development, which is the very antithesis of vibecoding.
I have no particular interest in Zig as a language but definitely feel some empathy here. The industry is changing in ways that many of us are struggling to process.
I mean, if they really care about software correctness, I wonder why take a very discutibile position and say that "safety doesn't matter if you don't use the correct process". Yeah, I mean, having some guardrails is better than none, right? If they really cared about correctness, they would really strive to put all the possible guardrails in place, wouldn't they? Maybe they are bitter because their fav language is not as popular as the other?
But there are so many languages, I wonder why picking on Rust specifically.
zig is reasonably established. the llms write pretty good zig. see project linked below which is almost entirely llm-written
> And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code
why? because one project that was shipping fast made a dog's breakfast of it?
> why open yourself up to memory unsafety on top of everything else?
this can be addressed by third parties in the reasonable near-term. for example:
https://github.com/ityonemo/clr
the zig team says that in the future stabilizing the IR and providing an API will happen.
> nobody can trick me into mistaking lesser stars for my true destination
The author seems to be in some level of denial around compile-time safety checks. They're right that runtime safety errors are an issue, but it feels wrong to discount compile time checkers when it can save a lot of yak shaving.
What makes you think that?
> I wonder why picking on Rust specifically.
I did not see that. What did I miss?
EDIT: doesn't really answer your question. Just reminds me of a good ol' flamewar.
When I make software, this is my sorted list of priorities:
It doesn’t matter that your project has no bugs if it’s a rugpull, or you’re otherwise working on user-hostile software.
It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs.
It doesn’t matter that your software is a beautiful canopy of abstractions, if it’s unbearably slow or nobody is able to maintain it, let alone add new features.
Sometimes I run out of steam, sometimes I go down the wrong path, and some other times I deliberately take detours, but nobody can trick me into mistaking lesser stars for my true destination: I do care about my own developer experience, but only in the exact measure that it helps me deliver more software you can love that I and others can enjoy.
The ultimate goal is to maximize utility for the end user; everything else exists in service of it, and that’s my north star for making software.