SonarSource: Google’s Carbon language is a successor, not a replacement, for C++
This is a guest post for Computer Weekly written by Phil Nash in his role as developer advocate at SonarSource – the company is known for its platform that developers and development teams to write clean code and remediate existing code organically so they can focus on creativity throughout an entire code pipeline.
Nash writes in full as follows…
Despite popular belief, Google’s open source Carbon programming language is not a strict replacement for C++.
Instead, it is designed as a successor.
While that may sound like the same thing, the important distinction is that it is intended to be used alongside C++. The interop story is the most important part. This is different to, say, Rust – which is a different language in the same space – but you have to go all in on Rust.
You can mix C++ and Carbon in the same project – calling between each other seamlessly.
Fixing technical debt
Any developer who has ever used C++ has encountered major complexities and pitfalls with the programming language.
The biggest issues that Carbon intends to address with C++ are due to years (decades, in fact) of technical debt in the language that, because of the priorities of C++ evolution, cannot be addressed within C++ itself.
These include complexities in the language around parsing, keyword soup, modularisation, as well as getting a clean start on generics.
Carbon also aims to address the governance model: favouring a Benevolent Dictators (note: plural) model with an open evolution process on modern tools – rather than an international standard (ISO) that is optimised for representation of nations and corporations.
Built into the evolution model is the expectation of breaking change – and a tool-based approach to dealing with it.
SonarSource’s Nash: Any developer who has ever used C++ has encountered major complexities and pitfalls with the programming language.
There’s also a misconception that Carbon alleviates C++’s memory safety issues. It doesn’t actually address memory safety, at least not fully. There are some things that it can do to improve some cases.
For example, tracking uninitialised states better. But because it needs to interop so directly with C++ it suffers from many of the same memory safety issues for now.
The same can be said about Undefined Behaviour, which is another big issue that is mostly unique to C++ (although, also one of its biggest strengths). There is some scope for minimising UB, but it cannot be completely removed without becoming a different language with different goals. We already have those.
The interesting implication here is that, while Carbon may be an excellent choice for those who prioritise clean code, there will still be very good reason to augment that with static analysis tools.
C++ needs Carbon
To reiterate, Carbon is not a replacement for C++.
But the Carbon project is absolutely necessary as C++ has hit a brick wall in several important areas of evolution that it cannot address without changing its priorities in a way that cuts off many (perhaps the majority) of its users.
Attempts have been made to introduce versioning systems into the language to work around this, but they have failed – defeated by the very complexities of the language that they have aimed to address! C++ will continue to live and evolve for a long time and remain an important language, but its limitations are real and inescapable.
For C++ to succeed – it needs to be succeeded.
The project Tweets here.