I’m putting down a marker to counterbalance Daniel Lemire’s post, Best programming language for high performance (January 2017)?. Daniel concludes, essentially, that C and C++ still rule the category.
I’ve written a lot of C/C++ criticism for a couple of years now. (OK, more ranting than writing.) Partly this is because I work in computer security, and C and C++ are so very, very, very bad for security. However, I realize that security, while of vital importance to me, is of relatively little concern for most software developers, much less your average consumer, who doesn’t know better anyway.
And yet, I am confident in saying that C and C++ are, essentially, dead, like a chicken without a head that is still wandering the barnyard. They are dead like COBOL is dead: there are still COBOL programmers, and there are still important COBOL programs running every day, but it is clear that COBOL is not the future. The vast bulk of new code is not being written in COBOL. COBOL is in maintenance mode.
Unsafe languages are too hard to use
More important than security is the fact that C and C++ are simply too hard to program, compared to any safe language. Not only is it too easy to write a catastrophic bug in C/C++, it is even easier to write more ordinary bugs. And these bugs are very often not caught by the compiler; they are discovered months or years later, in production, often after the programmer who wrote them has moved on.
This is something that I have observed over a long period: my first programming class at Princeton was taught in Pascal! When you look at the programming language landscape over that many decades, it becomes clear that programmers are voting with their feet, and against C/C++. Just as with COBOL, the vast bulk of new code is not being written in C/C++. New programs are being written in safe languages, because they prevent many of the bugs of C/C++, catastrophic and otherwise.
The web is being written in Ruby, PHP, and Javascript. “Enterprise” applications are being written in Java and .NET languages. Smartphone applications are being written in Java and Swift. DevOps infrastructure code is being written in Go. Academia uses Python, R, Haskell, Ocaml. All of these are ever-growing niches that would once have used C/C++, but they have been taken over by safe languages.
There is absolutely no sign that C and C++ can reverse this; just the opposite. C/C++ frameworks for web progamming were tried and died (ActiveX). In smartphones, Android has always used Java, and in iOS, the future is clearly Swift, and not ObjC. Programmers love safe languages.
New programming languages are being created all the time, and they are all safe languages. No one is creating new unsafe languages. It’s not plausible to say that this is because C and C++ are perfect; even the staunchest proponent knows that they have many flaws. The reason that people are not creating new unsafe languages is that there is no demand. The future is safe languages.
I don’t know whether there’s definitive data on this but everything I’ve seen backs this up. For example here’s the Tiobe Index on language popularity:
You can see that in 2002 the unsafe languages (C, C++, assembly) combined for more than 35%, while in 2017 they combine for less than 20%. The long-term trend is consistently downward.
Safe systems languages attack C/C++ where they are strongest
Finally, consider systems programming, the niche that C and C++ dominate, and the niche where the high performance that Daniel focuses on is the most important. Everything I have said above argues that a safe systems language, if it can be built, will displace C and C++. And this is going to happen.
Many people are interested in safe systems languages and many people are creating them. My own attempt, Cyclone, was from way back in the early 2000s. Rust and other contemporary languages continue the effort. These languages do not rely on garbage collection for safety, and are therefore postioned to take over parts of the C/C++ niche which have been uncontested until now. Again, no one is creating new unsafe languages, even for systems programming.
Legacy code is not an issue
C and C++ advocates like to point out the false myth that legacy code will never go away. This is only true in the COBOL sense. The programs are still running but they are not relevant to what programmers are writing today. And legacy programs do get rewritten. Programmers love to reimplement programs! It’s considered one of the classic pitfalls—that only means that it happens again and again, and sometimes it succeeds.
The idea that there is too much code in operating system kernels to replace is also false. Consider that while iOS has a kernel written in C, it also has a much smaller kernel based on the L4 microkernel. Apple uses this for their “secure enclave,” which holds cryptographic secrets and fingerprint id data; in other words, when it comes to security, less code is better. Now, L4 is written in C, but it’s small enough to formally verify (seL4), and it’s small enough to rewrite in Rust (Robigalia is one example). Linux can run in a compatibility mode above a safe L4 kernel, or above safe hypervisor for that matter. Once the bare-metal software is written in a safe language, C is going to get squeezed from both the low end and the high end.
How to accelerate the death of C/C++
Invest in safe systems languages: give them better documentation and better developer tooling, build programs in them, build useful libraries in them, rewrite security-critical C libraries in them, use them from existing C/C++ programs.
Culture: the default when starting new projects should be to use a safe language; proponents of unsafe languages should have to argue for them.
We need a public health campaign agains unsafe languages and we should have an explicit goal of eliminating buffer overflows and memory corruptions.
These efforts will help, but even without them, the future of C/C++ is set in stone: death like COBOL.
Previously
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27.