[jtorsella]

If the existence of C cves in the kernel proves that it is impossible to write correct C, then by the same token any cves in any rust code prove the same thing about rust. This is such a lazy way of arguing. Say something about why the tradeoffs favor a more restrictive and less performant language or don’t, but don’t dismiss the work of many thousands of C developers that runs most enterprise systems with a knowing wave of the hand - it’s not serious.

[pjmlp]

So you want something more serious,

https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...

https://security.apple.com/blog/towards-the-next-generation-...

https://www.chromium.org/Home/chromium-security/memory-safet...

https://security.googleblog.com/2022/08/making-linux-kernel-...

Σ (memory corruption) + Σ (logic errors) ≥ Σ (logic errors)

So by reducing in 70% the costs of fixing the errors caused by those thousands of experts, as validated by the above reports, there is already a considerable reduction in software development expenses.

Lets see how serious those developers get to be around security issues, when liability finally takes off.

[jtorsella]

I appreciate that you are making an argument and will respond when I get a chance later in the day and after I read a few of the links - I’m familiar with like half of them.

[preseinger]

it is not anyone's claim that the existence of C cves means it is impossible to write correct C

the point that is being made (obliquely) is that manual memory management is not possible for human beings to do effectively at scale

at scale means across a broad demographic of programmers, working on a broad set of programs

if you wanted performant and portable then C was all you had for a long time, and there is a lot of good software written in C, but that does not mean that it is a good tool in perpetuity

strcpy and pointer arithmetic are basically not possible to get right

we need to move beyond this very low level of abstraction