It makes it less likely that those errors that we're familiar with from C get compiled and released. There's no debate there. It's all those errors that we're not familiar with from C that it won't do anything against.
Not to mention errors stemming from our own arrogance and short-sightedness, which no language can ever protect us against.
If it makes it less likely that some errors get out, and doesn't do anything against other errors, then overall it makes it less likely that errors get out.
Please tell me how Rust introduces more possibilities for remote code execution vulnerabilities (the most severe). We're not talking about errors as a whole here.
The only RCE classes unique to memory-safe languages that come to mind are, like, dynamic deserialization vulnerabilities (like the Rails one) and remote includes (like PHP). Neither of these are applicable to Rust.
errors are not zero-sum. There's no finite pool of error that we're whittling down - there will likely be new error types we didn't know about or introduced by the new code.
> It makes it less likely that those errors that we're familiar with from C get compiled and released. There's no debate there. It's all those errors that we're not familiar with from C that it won't do anything against.
Those "errors", by and large, do not result in security problems (especially remote code execution), whereas the problems in C largely do. For example, Rust does introduce a new category of error, "Option.unwrap() failed". But so what? Option.unwrap() is security irrelevant.
It doesn't make the person less likely to err overall, but it makes it less likely that those errors get compiled and released.