The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following:
Out of Bounds Reads => 18.6%;
Out of Bounds Writes => 62.7%;
Null-Ptr Deref => 8.5%;
Use-After-Free => 5.1%;
Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%;
I have to wonder about the applicability of these percentages to non-RTOS programming. I find it very interesting that 81% of CVE's are allocated to Out-of-Bound Read/Writes, with writes being the larges percent of those obviously.
Has there been any CVE cause analysis performed and publicly available? If so and the percentages bear out similarly to RTOS's across a spectrum of application/system types then there may be some clear cost/benefit analysis needed at the programming language design stage. Rust is a complex language with a complex type and lifetime system to achieve memory safety, and it is not an uncommon refrain that a simpler 'safe' language would be appreciated by many developers. If 80% of CVE's come from Read/Write errors on array access, then a language that enforces strict memory access semantics, but forgoes the rest of Rust's complexity regarding lifetimes and type system complexity would achieve a very large portion of exploit prevention at a minimal cost.
Additionally, if you prevent Null types in the type system the language would then prevent 90% of CVE causes, again with a minimal amount of complexity.
I'm not certain that the above is correct, if the percentages play out in the large, or that devs would actively switch to a considerably safer, while being simpler language. But it certainly is thought provoking.