One of the first objections you will encounter if you suggest using a safe language is that “safe languages are slow.” That is, the same program written in C/C++ will inevitably be faster.

This is a false comparison.

A true comparison would compare a safe C program with a program written in a safe language. In other words, “the same program” should mean, at a minimum, that the two versions produce the same results on every input. Since the program written in the safe language will never execute a buffer overflow, it follows that the C program should also never execute a buffer overflow, on any input. This is a very high bar for C programs of reasonable size to achieve.

A C program is like a car without brakes driving down a windy mountain road without railings. It will certainly reach the bottom quickly, however, it’s fairly likely to do so by exploding in flames as it hits the bottom of the valley upside down.

Of course I have more than ample evidence to back this up. Let’s see… anything interesting in the news this week? How about the just-announced best paper from the 2015 USENIX Security Symposium, Under-Constrained Symbolic Execution: Correctness Checking for Real Code, by Ramos and Engler? It says:

We applied our three built-in checkers to over 20,000 functions from BIND, OpenSSL, and the Linux kernel and discovered 67 new bugs, several of which appear to be remotely exploitable. Many of these were latent bugs that had been missed by years of debugging effort.

In my experience, no amount of research, no amount of CVEs, and no amount of core dumps will convince a certain crowd that they are writing unsafe programs. To these folks, I say: go away. My words are not for you.