Google launched Carbon, an experimental language, last week, but industry skepticism clouds its future as a C++ replacement.
C++ is a mainstay of enterprise development, but it has drawbacks, and some developers have argued that it needs a replacement. The reasons for this are many, including code that is difficult to learn and read, issues with safety mechanisms and lack of suitability for modern hardware architectures and environments, said Chandler Carruth, principal software engineer at Google, during his keynote at CppNorth conference last week. Carbon will build on the C++ ecosystem in an effort to solve these issues, providing interoperability and easier migration, he said.
Carbon is touted as being well suited for projects with a large amount of C++ code. However, switching to a new language won't be easy.
"The challenge is that there's a lot of C++ code out there," said Andrew Cornwall, a senior analyst at Forrester Research. "Changing the language would mean you'd have to rewrite a lot of tricky-to-get-right C++ code, sometimes decades after the original implementer has retired. It wouldn't be impossible, just expensive."
In addition, modernizing C++ may be a moot point. Developers who want new language features have already moved to different languages such as Rust, a programming language backed by Google and Microsoft, Cornwall said.
Addressing coding quirks, security issues
When C++ inherited C, it bootstrapped the entire C++ ecosystem, which was essential to its success, Carruth said during his keynote. However, alongside the pluses -- including fast migration -- came coding idiosyncrasies.
"For example, we put co_ in front of keywords because we're terrified of breaking existing code," Carruth said.
The many quirks of C++ make it a complex language; the syntax can be difficult to understand and write, which can lead to errors and bugs that are expensive and time consuming to fix, said Morshed Alam, founder and editor at Savvy Programmer, a programming learning site. In addition, C++ is not well suited for developing enterprise applications, he said.
Cornwall agrees that C++ is not the best language for enterprise development, but it has been sufficient for building a range of core infrastructures.
"[C++] is powerful," he said. "It allows you to do lots of things -- including shooting yourself in the foot."
Another issue with C++ is memory safety, which poses a significant security risk, said Dhaval Sarvaiya, co-founder of Intelivita, a game, web and mobile app development agency. C++ data stored in memory doesn't have access or overwrite controls, which makes it vulnerable to buffer overflow attacks, where bad actors crash, control or modify a process's internal variables.
But while a C++ replacement needs to address memory safety, this is a major challenge and isn't a priority for the Carbon team, according to the team's GitHub page. "Our initial priority and focus is on immediately addressing important, low-hanging fruit in the safety space," Carbon said.
Open source development opens up problems
A major pain point with solving C++ issues concerns the existing and strict rules laid down by the International Organization for Standardization to achieve representation of nations and corporations in establishing standards, Google's Carruth said.
Representation makes sense if that's a developer's goal. It doesn't make sense, however, if the developer is addressing complicated problems such as the Technical debt that C++ carries, ranging from hard-to-understand arithmetic rules to syntax with the most vexing parse -- where code doesn't do what it appears it should do, he said.
For complicated problems like these, priorities should shift to things such as making an effective team of experts with a good decision-making process, Carruth said. As a result of this shift in priorities, almost all Carbon development work will be done on GitHub with Google Docs for collaborative editing, he said.
"The evolution process is GitHub pull requests -- that's it," Carruth said.
However, this shift in priorities doesn't negate the fact that Carbon will have to deal with the same issues as C++, such as compatibility and users who want consistent builds, Forrester's Cornwall said.
"If Carbon succeeds and establishes a large code base, Carbon's committers will be forced to establish a process for accepting or rejecting new language features," he said. "That process will become as bureaucratic as the C++ process is today."
Most developers want languages to evolve slowly, and Carbon's model of allowing anyone to contribute a new language feature will hinder its adoption.
Andrew CornwallSenior analyst, Forrester Research
Carbon's open-source development model brings an additional problem. "Most developers want languages to evolve slowly, and Carbon's model of allowing anyone to contribute a new language feature will hinder its adoption," Cornwall said.
There's no easy fix
In the past, languages such as D and Objective-C have made some improvements over C++ -- but the huge C++ code base makes it a challenge to replace, Cornwall said. Rust is not an ideal C++ replacement because it is not source-code compatible with C++ and doesn't have classes -- a defining idea in object-oriented programming -- but it does support modern features such as more secure memory allocations that make it safer than C++, he said.
Compounding the issue is that the introduction of any new language -- even one that isn't experimental -- results in developer frustration, Cornwall said.
"Ask the developers who started on Swift or Kotlin when those languages first came out, and how they had to adapt as the languages evolved; they were often frustrated by having to revisit code they'd already written and re-write it to support the new version of the language," he said. "For a developer, there's almost nothing more frustrating than that."
Since Carbon is still in an experimental stage, enterprises are unlikely to adopt it, said Leonid Ivankin, an Android developer at MTS group, a mobile telesystems company. The most likely place Carbon will thrive are with startups that begin a project from scratch, he said.
"Google, as history has shown, can not only start projects, but also close them," Ivankin said, referring to defunct Google projects that have left developers in the lurch, including Noop, an experimental programming language, and AngularJS, a JavaScript open-source front-end web framework.
