Carbon, the Would-be C++ Successor
This topic is unrelated to the earlier post about elemental carbon.
Google unveiled Carbon Language: An experimental successor to C++ this week. The README explicitly suggests that if possible, you should use an “existing modern language” instead. So, why create Carbon at all? Because a lot of enterprise software has gotten itself wedged firmly between a rock and a hard place, and Carbon aims to be the lubricant that helps it get unstuck.
The rapid pace of technological innovation forces us to balance the cost and risk of using legacy technology against the cost and risk of replacing it. When, if ever, should an entire codebase be rewritten? Successful companies can and do replace whole systems, often piece by piece over a period of years. As with any refactoring—meaning, any change to the implementation that has no material effect on the interface—the question is not whether to rewrite, but where to draw the line between what we keep and what we replace today.
The single worst strategic mistake that any software company can make [is] to rewrite the code from scratch.
—Joel Spolsky, Things You Should Never Do, Part I, April, 2000; emphasis in original
The question du jour is: Given the rise of safe, performant, multicore-friendly languages like Rust, Go, and Swift, what are we going to do with our C++ code? If your immediate reaction is to snicker in doubt at the idea that C++ is suddenly obsolescent, then you haven’t been paying attention. This isn’t a matter of personal preference, or my-language-can-beat-up-your-language. The current crop of systems programming languages embodies a vital leap in our understanding of how software can and should be made.
If you wish to make an apple pie from scratch, you must first invent the universe.
Despite their shortcomings, C and C++ have always been protected by a moat of run-time efficiency and low-level hardware access that other languages could not offer. That situation is no more. We now have safer, easier-to-use languages with excellent tooling and real-world usage at scale. The moat has been bridged. The barbarians aren’t merely at the gate, they’re in the keep. If the thought of retraining your developers and migrating your C++ code to an entirely different language strikes fear in your heart, Carbon may offer a helping hand that seems less barbarous.
Rewriting code in a new language poses a technical challenge that other refactoring does not. The line between what to keep and what to replace must be drawn around a process or binary linkable object, even if the old code must be refactored to introduce such a boundary. C++ makes such lines especially difficult to draw: It has no standard networking functionality or Application Binary Interface (ABI), and it relies heavily on compile-time features like templates and function overloading that cannot be exposed through traditional Foreign Function Interfaces (FFIs). The reason Carbon exists is to maintain C++ compatibility, including the compile-time features, while offering “an incremental path towards a memory-safe subset” of the language.
Whether Carbon will succeed in its goal of easing the modernization of enormous codebases remains to be seen. C++ won’t go quietly. Some amount of it will be with us for decades to come, much as COBOL and cockroaches survive in the deepest, darkest pits of the corporate world. If you absolutely cannot migrate to a safer, more desirable modern language, Carbon is here to help pull your C++ code out of the pits. The proviso is that plenty of cockroaches are coming along for the ride.