The reason I focus on the memory safety difference is precisely to not minimize its importance. It's far more salient of a difference than whether a language "feels big" or not. Talking about whether Zig requires "a little more manual labor" than Rust is missing the enormous elephant in the room.
I think the people who like Rust are in a room where they perceive that elephant to be enormous and people who like Zig are in a room where they perceive it to be much smaller.
You can certainly argue whether or not their perceptions are correct, but I generally believe that people are entitled to their priorities.
Either way, you initially stated confusion about why people stated certain opinions about Rust, C++, and C. I tried to explain why people might hold those opinins. You are then arguing that they shouldn't hold those opinions. Whether or not that's true, a prescriptive claim is orthogonal to understanding what's actually in their heads.
The elephant is enormous, because the C crowd is not living up to what they need to do to actually make the lack of memory unsafety unimportant. C is like ruby in the sense that the untyped nature of ruby might initially buy you a productivity win, but in the long run it requires you to dilligently write impeccable unit tests, since even the most basic correctness checks can only be done at runtime.
Actually that's wrong. In C you will need exhaustive formal verification, because UB doesn't cause minor miscompilation anymore. Formal verification is far more onerous than whatever Rust is demanding.
pcwalton is responsible for a lot of the rust borrow checker, so, not a neutral opinion. ive posted it too many times on this thread but it seems borrow checking analysis may be possible for zig (if the zig team should want to)
I highly suspect it won't be feasible for the same reason it isn't feasible in C++: you could technically implement it, but tons of existing patterns in the ecosystem would become impossible to express, so in practice it would end up creating a different language. From a skim, the CLR project you linked to claims that metadata will probably be needed in order to enforce aliasable xor mutable, and I agree.
> tons of existing patterns in the [C/C++] ecosystem would become impossible to express
Well, the really harsh way of putting this is that the patterns break for a reason; they rely on global claims about the program, so they aren't genuinely robust in the context of code that sits within a large, constantly evolving codebase that can't be practically surveyed in its entirety. Rust is very good at picking patterns that can be verified with a comparatively straightforward, "local" analysis that broadly follows the same structure as the actual program syntax. Safety claims that rely on "global" properties which cannot be kept within a self-contained, module-like portion of the code are essentially what the unsafe marker is intended for. And this is exactly what idiomatic C/C++ code often gives you.
This is actually why I think that proposals like Safe C++ should get a lot more attention that they do at present. Yes, Safe C++ changes what's idiomatic in the language but it does so in a way that's broadly sensible (given our increased attention to memory safety) especially in a context of "programming in the large".
you can go a long way before getting to aliasable xor mutable, and the metadata doesn't require a language change, theres an example in there on how to bind metadata with no language changes.
