> shows you're really not familiar with the PL design space (which is fine actually but you should probably not be arguing about academic domains you're not familiar with).

Oh, I'm familiar enough (my job requires me to be), but I wanted to list languages people here have heard about. Also, I'm not arguing about an academic domain. Having spent just the other night at a gathering with PL researchers in the UK, some interested in Zig, I know that even if we restrict the discussion to academia alone there is absolutely no consensus over the matter. It is an empty and false assertion, plain and simple.

Also, let's not forget that Rust leans quite heavily on a garbage collector, too, albeit a rather crude one.

> The idea that Rust may cause more bugs than it avoids is backed by zero evidence.

I never claimed that it does. I said we don't know which approach leads to more correct software, and that anyone who says we do is simply unfamiliar with the field or misleading. I explain more below.

> that “maybe Rust some unknown type of bugs we cannot be sure” is a fallacy

That's not what I meant at all. Just as an example of things that Rust's design could adversely affect to the point of adversely affecting correctness, consider two techniques that have proven extremely valuable in improving software correctness: code reviews and tests. A complex language with a lot of implicitness, long compilation time, and possibly longer code-writing time, can slow down or hinder these two techniques. Those issues are related to why so many in software correctness research today focus on reducing soundness; soundness has a cost of slowing down very effective unsound techniques, and given that full-soundness is something most have given up on, whether the price is worth it is always a hard question with no easy answers.

> Zig doesn't particularly address “correctness”, more than any typical language...

I think it does, and Zig's designer thinks so too (in the sense that he's designing the language and it tools with correctness as a primary goal) -- I don't know if it's more than any "typical" language (working on a "typical" language myself and caring a lot about correctness, too), but certainly not to any lesser extent than Rust. In particular, there's a very strong emphasis on explicitness over explicitness (no hidden control flow, local reasoning) and there's a strong emphasis on fast compilation and good testing support (including a design that makes isolating units and testing them easier) to facilitate faster and more rigorous testing.

Those who arrive at correctness from academic PL are often unfamiliar with such reasoning, which is now increasingly more common in formal methods research where the power of unsoundness is now appreciated.

> There is no trade-off in correctness between those two

I gave an example above that explains why some people think there could well be. No one can claim that either Zig or Rust yield more correct software, because we really don't know.

> One can argue that “programming mistakes” ...

That's not the argument at all. Memory errors are, indeed, both tricky and dangerous, and it is important to avoid them, but not at the expense of missing other, equally tricky and equally dangerous bugs.

> If you want to see “Zig safety story” in action, have a look at the only commercial user of the language, and go search for “segfault” in the github issues…

If you choose to eliminate bugs of class Y, you'll have none of them, and if you don't -- you will. This has no bearing at all on the question of overall correctness, which is what memory safety ultimately aims to serve. That is why there's no consensus over it.