The point I'm making is that I don't believe Zig can be made meaningfully memory safe without breaking compatibility to the extent that memory-safe Zig would effectively be a different language, any more than C can.
I tend to agree, but writing code in a memory-safe language is not the goal. The relevant goal on that particular front (and it is not the only goal people have when writing programs) is to maximise the resulting program's correctness within some effort budget and other requirements (such as memory consumption etc.). Using a memory-safe language is one approach toward achieving that goal, but if that safety comes at a cost of added effort, then showing that's the best approach depends on claims that are hard to verify without a lot more empirical data. The only theoretical justification could be that more soundness results in more practical correctness, but if that were the case then there are languages that offer more soundness than Rust. In other words, if Rust is generally superior to Zig because it offers more soundness, then other languages are superior still. Indeed, soundness is not considered the best approach to attaining every property in general because it can be more expensive than other approaches that achieve the desired outcome, and Rust clearly recognises that.
Rather, both languages' correctness-related claims rely on them being in some better or worse effort/correctness sweet spot, and that can only be measured empirically for those two specific languages. Crucially, results comparing Rust to C or C++ are not relevant. Zig offers more soundness than C, and even if it offers the same soundness as C++ (and I disagree -- I think it offers more) the language's claim is that its simplicity assists correctness. We can only tell to what extent that is true with more empirical observation; I don't think there can be any good guess made here regarding the size of the effect.
some correctness matters more than others. for a web browser, i would rather use a browser that is buggy/janky/crashy but doesn't give random websites arbitrary native code execution over a browser that is logically correct except for giving random websites rce. the languages that are more sound than rust are probably worse among some axis like ease of use, expressivity or performance. even if they weren't, they're probably not going to buy me much more than a slightly less buggy/janky/crashy browser, once you no longer have exploitable memory safety bugs.
Sure, but once soundness starts trading off other properties that may be important even for that kind of correctness, it is not necessarily the best approach. You don't care what the cause of the exploitable remote execution vulnerability is, and remote code execution is a real vulnerability even in fully memory-safe languages.
If you look at MITRE's CWE Top 25 [1], #2 (Out-of-bounds Write) and #6 (Out-of-bounds Read) are soundly eliminated by both Zig and Rust. It is only when it comes to #8 (Use After Free) that Rust's additional soundness comes into play. But because it comes at a cost, the question is to what extent eliminating #8 adversely impacts the other top vulnerabilities, including those higher on the list. It may be the case that eliminating the eighth most dangerous vulnerability through sound language guarantees may end up being worse overall even if we're only concerned with security (and it isn't the only concern). We can only try to assess that through empirical study.
if you looked at the clr project you would find a credible claim that it doesn't have to be an "effectively different language", that there is a real possibility that "minor annotations are sufficient".
> I don't believe
Of course, we're debating against a belief, and you have plenty of reasons to not believe it that it will be impossible to be swayed by any sort of evidence, and you will always find a way move the goalposts.
