Sounds like damage control. I have to say, for a brilliant guy, andrewrk knows nothing about marketing. The fact that the Zig project can make this significant of a change to their core-value because "trust me i know what I'm doing", makes it impossible (for now) to rely on this in any type of a widely-deployed Enterprise setting. This just made the highly risky move of moving to Zig make it darn near impossible.
What he should have done is announce a project at the same time that will maintain the current developer experience, even if that project is not part of the zig foundation. The developer doesn't care about how he builds zig. They want 1) download 2) use. It doesn't matter from where. If today it's directly from zig, and tomorrow it's from elsewhere to download a combined package, that 's all the devs needed to hear.
Unfortunately there's a lot of people on the internet who haven't even used Zig nor plan to use it anytime in the future and who just enjoy to create drama by amplifying any decision with a hint of controversy around it (also see the 'unused variables are errors' drama which turned out to be a non-issue after it was actually implemented).
Unrelated to Zig, it's the exact same thing with "WASM can't access the DOM" btw, comes up everytime when WASM is in the news, but is a complete non-issue in practice for anybody actually using WASM, and I'm sure each popular software project has at least one such 'drama issues'.
The 'LLVM divorce' has been announced waaaay ahead (maybe years) of any actual steps to make that happen, for a language ecosystem that's still unstable anyway, and with the promise that a solution will be in place before LLVM is actually kicked out.
Not sure what else could have been done better, and as other have said, this sort of decision making process is much preferable to a committee approach.
The LLVM divorce has also gotten criticism since it first was announced and we have so far not seen any complete solution. Maybe we will land in one but if people did not voice their concerns there is no reason to think such a solution would be found.
What is there to criticize though? What "solution" is necessary?
LLVM is not and was never going away as a compiler backend, it will just not be the default one and you will be able to compile zig without it (though in practice everyone will for prod releases)
The fact that WASM requires a JS is a marketing fail and misses what could have been a marketing opportunity to make the claim, "finally an alternative to JavaScript".
In this case, this is not a non-issue. If you look at the original github issue, it does a lot of damage, followed by a lot of confusion, followed by a damage-control post that shouldn't have been required if it the original issue was written with more care. It wasn't, because the marketing aspect of Zig was not the focus -- the technical issue was. So it blew up. Hopefully it'll be a lesson learned, but I suspect it isn't. It will take 20 more of such incidents before it sinks in.
As far as it was "announced years ago", I don't see how that matters. The people who are seeing the issue now, and this discussion weren't there to see the announcement years ago.
But I do understand what you're saying. You're point is that the onus is on the the reader to the do their research before overreacting. That's a perfectly fine position. I have a counter opinion which is that the person making the statement / claim / annoucement, simply be understanding of the implication of their statements.
This thing blowing up should not have been a surprise to anyone. Sounds like it would have been to you, so the fact that it blew up is evidence that you would have misjudged. Unless you also agree that the initial message should could have been better worded, in which case, what exactly are you disagreeing with?
Zig's not at version 1.0.0 yet. Yes, it would be very irresponsible to use current-day Zig in a widely-deployed Enterprise setting. The release notes explicitly acknowledge Zig is currently immature, and is currently only suited to people willing to participate in the language development process.
Wait what is controversial here? Removing llvm as a dependency and making it a (probably default available) plugin instead? Seems "obviously good", if you ask me.
Weird machinations around projects that are and aren't (but are privileged because he's the creator) part of the zig foundation would be more concerning, quite frankly.
What he should have done is announce a project at the same time that will maintain the current developer experience, even if that project is not part of the zig foundation. The developer doesn't care about how he builds zig. They want 1) download 2) use. It doesn't matter from where. If today it's directly from zig, and tomorrow it's from elsewhere to download a combined package, that 's all the devs needed to hear.