That is absolutely true and I don't disagree that it is possible to write C securely. But I would contend that the statistics you mention reflect differences i

That is absolutely true and I don't disagree that it is possible to write C securely. But I would contend that the statistics you mention reflect differences in programmer attitudes and skill, and should be controlled for in any comparison. The same level of care and skill in another language will very likely lead to even fewer vulnerabilities, as long as that language doesn't have its own even worse foot-guns. The priorities of the language are just different. When I use C, I get fairly decent performance basically for free, but I have to work and maintain discipline to obtain safety, high-level abstractions, etc. I'd much rather work in a language where I get memory safety and basic type-sanity checks for free and have to work for performance. This should really be the default, as it's much more in line with the end-user's needs. When I vet software, it's extremely easy to tell whether it is performant, but it takes serious auditing in C to tell whether it is even memory-safe, let alone actually correct and relatively free of side-channels, etc. The thing about memory safety is that it can be compromised almost anywhere in your code. Your attack surface compared to what _should_ be exposed to attackers is incredibly large. If I can trust the memory-safety of a codebase I am auditing, I don't have to spend nearly as much time on it because I can focus on the parts that actually deal with the intended purpose of the code rather than having to go through every allocation and every memory access in the entire codebase with a fine-toothed comb. Why do we continue to prefer a language where it's easy to achieve the only goal that is obvious when not achieved, at the expense of requiring great care and discipline 100% of the time in order to not instantly and fully compromise the harder-to-evaluate goals that actually matter (especially in security-oriented software such as openssl)? In this case, bad buffer handling in a data structure deserializer gave attackers a free ride past man-years (perhaps man-centuries) of work writing and auditing security-critical code. Surely it'd be better if these kinds of failures were at least interesting rather than an endless parade of careless mistakes that could literally have been caught by trivial automation in the compiler. Especially when there are so many good compilers for so many good languages that already do it.