Comment by pcwalton
1 year ago
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.
> It's far more salient of a difference than whether a language "feels big" or not.
You clearly don't like it, but it seems many people disagree.
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.
2 replies →