I'm sorry, but you don't understand how Rust's safety guarantees work. There would be multiple CVEs filed against almost every single library in libc and C++'s

I'm sorry, but you don't understand how Rust's safety guarantees work. There would be multiple CVEs filed against almost every single library in libc and C++'s standard library if we used the same standards as Rust for those two. We don't, because it would obviously be pointless to do so, because C and C++ libraries generally don't have explicit safety guarantees, and those that do usually put an extremely high correctness burden on the caller. AFAIK, virtually all of Rust's CVEs found to date would go away (assuming the rest of the code remained the same) if Rust libraries just declared all the APIs in question "unsafe," which is basically what C and C++ do. The Rust standard library, your "random" example here, would have 0 CVEs by this metric, and so would pretty much every Rust library (the vast majority of Rust CVEs are filed against libraries). In other words--a library can't be blamed for being insecure if it never makes any security promises in the first place. Rust libraries make stronger and more explicit guarantees, and the code is encapsulated in a much smaller region of the program, so it is easier to prove that they are in violation of their contract; but it emphatically does not mean that it results in more end to end vulnerabilities. Claiming that Rust simply isn't used in enough, or critical enough, places yet to have real exploits like C programs do is pretty naive, as it's started to be used in places like Android's bluetooth stack. In fact, in practice there's even more of a gap than this--most C and C++ programs don't report CVEs even for reliably reproducible instance of UB unless you can demonstrate a full end to end attack chain, and many won't even fix or prioritize them if they consider it "benign" UB (what this means is anyone's guess!). Even projects like Chrome that actually care about security often won't upgrade UB bugs to CVEs if they believe (erroneously or not) that other hardening mechanism in the program will prevent it from being used as part of an RCE chain. Applying the same standards people typically do to C and C++ projects (an end to end exploit chain), I'm not sure whether there would be a single known Rust CVE in any widely used program. Basically: the standard of evidence for a CVE in your average C or C++ program is astronomically high, while in Rust it is extremely low. Any attempt to decide which language is practically safer by counting CVEs (which is in any case bad methodology) needs to have awareness of this fact if it's trying to actually measure anything real.