Despite a host of up-and-coming alternatives, C++ is still a force to be reckoned with, certainly in the legacy-fraught high-tech industry. In a series of articles, High Tech Institute trainer Kris van Rens puts the language in a modern perspective. In our new 4-day training course, Kris van Rens introduces participants to the language basics and essential best practices.
“There are only two kinds of programming languages: the ones people complain about and the ones nobody uses.” This is a famous quote attributed to Bjarne Stroustrup, the creator of C++. Hidden in it are a couple of truths.
First and most obvious: no single programming language is perfect for solving every problem in every domain. Especially when a language is advertised as “general-purpose,” like C++, it can be applied nearly everywhere, but chances are there’s a mismatch between the tool used and the tool required. For example, it’s perfectly feasible to write a complete web application in C++, but is it the right tool for the job? Personally, I wouldn’t say so.
Then, as a language evolves and ages, it’s very important that there’s a clear process to deal with (breaking?) changes. A conservative and safe approach is to maintain backward compatibility from the first stable release onward. This is the approach C++ has followed and abided by for decades now – which, unfortunately, also blocks the adoption of some language improvements.
Another hidden truth from the opening quote: the user base is extremely important. You could design the most beautiful, safe, secure and pleasant programming language ever. But what good does that do if only a few people are using it?
Good contenders
A good model for programming language significance is a mechanical flywheel; the larger the user base, the bigger the flywheel and rotational velocity. The user base size is defined by the number of active developers, existing code bases, separate code base interdependencies and other factors like third-party integration support. For C++ at least, this flywheel still has enormous momentum. Yet, there are forces at work slowly eating away at this momentum. Other languages in the systems programming realm are winning over parts of the C++ user base.
Previously, I wrote about the announcement of the Carbon programming language, a C++ successor started by Google, but there are many more alternatives. Some of them, like Zig, Odin and Go, are more aimed at C rather than C++ – I’m not going to cover these here. Then, for the sake of being pragmatic, I’m going to skip languages that are too small or experimental, like Nim, Val, Vale, Cpp2 and Jakt. That leaves only a handful of ‘serious’ alternatives, including Rust, Swift, D and Circle.
What makes a language a good contender for large-scale C++ user base adoption? We can start by looking at the properties where C++ generally falls short. For example, does the alternative have a ‘modern syntax’ throughout? Does it feature built-in guaranteed safety of some kind, like memory or math operation safety? Does it come with a tooling/packaging ecosystem? C++ interoperability is another very important aspect. A C-style foreign function interface (FFI) is nice, but it feels like a downgrade if we have to adapt our C++ interfaces to that.
Having one of these properties isn’t enough, though. A modern and clean syntax is very nice but isn’t going to cut it on its own. A great tooling ecosystem is fantastic but, again, not good enough on its own. In my opinion, if you want to have any chance of succeeding C++, you’re going to need at least the following three ingredients: a 10x improvement on some aspect of the language, guaranteed memory safety and good interoperability with existing C++ code.
Ticking the boxes
Looking at our serious alternatives, a language like D is missing the 10x improvement. This is why I think it has never really taken off, even though it’s already 20 years old. One-man project Circle is very impressive, especially for its language development experimentation capabilities. And above all, except for taking feature flags to enable language improvements, it’s completely compatible with C++. Unfortunately, Circle isn’t openly governed and lacks guaranteed memory safety. Swift comes with excellent tooling, but it’s too focused on the Apple platform and it has only partial/work-in-progress C++ interoperability.
Rust ticks most of the boxes. It even has quite a decent user base already. Although it also lacks true, mature C++ interoperability, it’s the most promising contender today. More on Rust in my next contribution.
