Why Google Released Carbon. How to start thinking around Google… | by Pen Magnet | Aug, 2022

How to start thinking around Google Carbon

Photo by Terry Vlisidis on Unsplash

In the most recent CppNorth conference in July, Google released its C++ descendent programming language called Carbon.

Google has just released 0.1 now. Carbon 1.0 will be available around 2024–2025. The purpose is to allow the developer community from disparate origins to have enough representation early on.

At its launch, Google cited Carbon as a natural succession in a pattern of language evolution:

  • Microsoft improved upon JavaScript to create TypeScript (though this is often subject to debate in the programming community)
  • Google improved upon Java to create Kotlin
  • Apple improved upon Objective C to come up with Swift

If you observe, in all the above cases, improvement efforts are concentrated on bringing more static type checking to prevent type mishandling and, thus, runtime disasters, including crashes and memory leaks.

1*k8C tiGCSiLCqPDBDlL4iA
CppNorth presentation by Google

Google intends to do the same for C++, with Carbon.

It’s a transformative step. At the same time, it brings so many thoughts, ideas, and questions to the forefront of the programming language arena.

Programmers have been historically embracing the adventure of creating a viable C++ alternative.

In the 90s, Sun Microsystems came up with Java. Its main selling point was to run cross-platform inside a VM to smarten millions of appliances. It attained quite by retaining C++-like OOP but eliminating the ugly pointer management.

Java enjoyed a perfect timing, too. The web had its Big Bang moment, and Java became the de-facto language for application servers. Java applets occupied browser space for some time. Within a decade, Java’s syntactic sibling Javascript took over the web. Javascript’s journey didn’t culminate even after its server-side counterpart Node.js. It’s still growing.

Replacing C++ was at the core of language evolution all that time. Having a garbage collector-backed runtime, Java eliminated the memory management problem but fell short of attaining the native performance of C/C++ because of its architecture.

C/C++ continued to be at the core of both commercial and non-commercial systems that were developing in parallel:

  • Google, Facebook, Amazon, Twitter, and Bing — all have their core application logic written using C/C++.
  • The Android operating system runs on Linux kernel, which is written in C. Linux is written in C. Mac OS and iOS are offshoots of BSD-based Unix, which is heavily written in C.
  • Git and Subversion version control systems are written in C.
  • All databases (Oracle, Postgres, MySQL, IBM Db2, SQL Server — the list is endless) are written in C/C++.

C/C++’s unbeatable performance is why it is still the #2 on the list of the most preferred programming languages. (Last year, it was #1, but it got replaced by Python this year.)

Yet, it was and still is the problems with C/C++ that lead the programming community to embrace the quest for the next panacea programming language.

The main problem with C/C++ is its draconian syntax. It’s a steep learning curve. This results in a huge technical debt built inside gargantuan codebases. Even experienced programmers fear refactoring such codes.

C/C++’s ugly syntax results into steep learning curve, creating a huge technical debt, which creates a vicious cycle

When parsing a language isn’t intuitive, developing tools that support it is difficult. IDE support, newbie dev’s main weapon against a programming language, is minimal for C/C++ because of its syntax. Microsoft Visual Studio ruled the space for a long time, but it was proprietary. The competition fails to offer much in terms of cost-effectiveness or features, too.

Because of its performance monopoly, maintaining C/C++ has become a task of ever-increasing challenge. Coupled with its complexity, it generates a vicious cycle made of the following three factors:

  1. Steep learning curve
  2. Less developer love
  3. Technical debt

In a nutshell:

  • Due to the steep learning curve, fewer developers learn C/C++, and even less master it.
  • Maintaining huge, old, and complex code falls on the shoulders of below-average developers, who perform quick fixes, contributing to the technical debt.
  • Bug-ridden code poses a steeper learning-curve challenge for the next generation of coders. The cycle goes on.

Programmers don’t want to put themselves in a position to choose between performance and simplicity. Why can’t they have both?

There are two ways to achieve it:

  • Improve C/C++
  • Create a new language that eliminates memory management but is still as performant as C/C++ (hence, interoperable with C/C++ due to its large existing codebase)

Then, there was Rust.

Purity often isn’t the reason businesses want to replace an ugly thing. As long as it makes money, it stays, despite its pitfalls.

Microsoft, as usual, was the first to correlate C/C++’s ugliness with its dwindling profits.

As of 2004, memory-related errors cost industry about $250,000 each

Programs blow up when programmers do a bad job with memory management (not always due to their own inability). When the language is performant, they blow up frequently before it can be fixed. And every blow-up costs huge money to customers, which eventually falls on the shoulders of the software providers. None other than the largest enterprise cloud providers can understand this thing.

In C/C++, despite its long history of evolution, this is inevitable.

According to the most conservative estimate by Microsoft, dated as early as 2004, memory-related errors cost the industry about $250,000 each. As a result, Microsoft has heavily begun to move most of its mission-critical code from C/C++ to Rust.

Started by Mozilla in 2010, Rust has its biggest backers in all leading tech companies: Microsoft, Amazon, Google, Facebook, and Apple.

AWS also runs its lambda-function deployment code using Rust. Facebook uses Rust, too.

Google planned to use Rust in Linux Kernel, which powers Android.

Google’s Carbon has a strong similarity with Rust syntactically.

One of the most striking parts that grabbed my attention from the docs is this section:

Any path to safety must preserve performance of C++ today. This rules out garbage collection, and many other options. The only well understood mechanism of achieving safety without giving up performance is compile-time safety. The leading example of how to achieve this is Rust.

While announcing Carbon, Google hasn’t criticised Rust. In fact, at one point in CppNorth, Carruth (lead Carbon developer) advised those using Rust to continue to use it.

Carbon is for those developers who already have large codebases in C++, which are difficult to convert into Rust.

In that sense, Carbon could be expected to be on a similar level as Rust (the syntax has many similarities with Rust). Yet, at some point, it could aim to evolve beyond it.

Google’s Golang was a success. It often comes up as the fastest backend development language. It is statically typed and one of the easiest to learn. Since its inception, it has continually risen in TOIBE popularity index.

Flutter wasn’t as good on iOS as it was on Android, thus often invalidating its cross-platform existence

As part of its cross-platform initiative, Flutter, Google came up with Dart. Backed by a huge community support, it got faster adoption. However, some of Flutter’s performance claims fell flat following initial euphoria. Dart’s initial release lacked basic features such as hashing for a long time — a sign of amateurish language-building approach.

Due to its poor community management coupled with heavy dependency on community-driven packages, Dart’s iOS offerings lacked many features compared to the native platform, thus wiping out its reason to exist as a truly cross-platform development framework.

Despite big companies adopting it, Dart never became the heavyweight forklift Google advertised it to be, and Flutter remained a community effort in line with React Native — Google’s ad-platform sibling’s brainchild destined to create cross-platform apps faster for itself, by getting community-developed controls.

Being built in open, some may think Carbon development may follow a similar trajectory as Dart due to its over-dependence on community.

There is no reason to be pessimistic about Carbon, though.

Here, Google’s aim is rooted in evolving C++ — a task that became a thorny path due to the extremely bureaucratic evolution of the world’s most archaic application-level language.

To achieve this aim, Google has made Carbon open quite early in the development (1.0 is awaited in 2024–25). Google has also made it a rule not to have any single organisation contribute more than 50% to eradicate monopolistic hijacking.

Here is an excerpt from Carbon’s GitHub Readme:

C++ remains the dominant programming language for performance-critical software, with massive and growing codebases and investments. However, it is struggling to improve and meet developers’ needs, as outlined above, in no small part due to accumulating decades of technical debt.

Incrementally improving C++ is extremely difficult, both due to the technical debt itself and challenges with its evolution process. The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax.

In a nutshell:

  • Google acknowledges C/C++’s unbeatable performance and large codebase
  • It admits that it has created a huge technical debt that is unsustainable for the industry at large
  • It is difficult to improve upon C++ due to the bureaucratic nature of (possibly conflict-inducing) changes to C++ standards. While Google does not specify what is meant here, feel free to supplement with examples if you have any.

Hence, a new language.

Cross-platform development using C++ is a thing.

It was first unveiled by Dropbox when it launched its Djinni at the 2014 CppCon conference.

Djinni is a code generator that takes IDL (interface definition language) as input and produces C++ class skeletons compatible to be used from Objective C and Java.

IDL is nothing but a header file equivalent of C++ or a class interface equivalent to Java.

The generated code (.cpp and .hpp files) is known as C++ platform bindings. It can be used as common business logic below native layers (Objective C+Swift or Java+Kotlin).

Despite its involvement with C++, in the mobile space, where developers are hungry for cross-platform, this approach is low-hanging fruit. Cross-platform C++ could power mobile apps involving heavy GPU or ML operations for maps, reality games, or video rendering.

It wouldn’t be wrong to assume Google Carbon might be aiming to replace C++ in this area.

Back to the docs. Reading from its high-level goals, Carbon supports:

  • Generics and templates
  • Tuples
  • Interoperability with and migration from existing C++ code (source-to-source translation for idiomatic C++ code)
  • Same memory model as C++ (an object memory footprint in Carbon would be identical to that in C++)

Carbon will not aim to:

  • Be backward compatible
  • Be a language with stable ABI
  • Support platforms that cannot update their compiler and linker alongside the language.
  • Carbon’s GitHub is currently ripe with fairly low-level programming concept discussions and docs — a sign it is truly an effort taking place in public. One of its design principle docs also cites:

Culture eats strategy for breakfast.

It is clear that beyond unveiling design goals, Google has guarded very little before releasing the trunk. The repo is quite live. As I am writing this article on Saturday evening EEST, someone (if not some release bot) has pushed changes just 14 minutes ago:

# Install bazelisk using Homebrew.
$ brew install bazelisk

# Install Clang/LLVM using Homebrew.
# Many Clang/LLVM releases aren't built with options we rely on.
$ brew install llvm
$ export PATH="$(brew --prefix llvm)/bin:${PATH}"

# Download Carbon's code.
$ git clone
$ cd carbon-lang

# Build and run the explorer.
$ bazel run //explorer -- ./explorer/testdata/print/format_only.carbon

Google carbon explorer

Google Carbon explorer is a validator that can track design changes into Carbon language specification. It is implemented as a language interpreter rather than a compiler.

According to GitHub:

It is an implementation of Carbon whose primary purpose is to act as a clear specification of the language. As an extension of that goal, it can also be used as a platform for prototyping and validating changes to the language.

How to play with Google carbon without installing it?

Compiler-explorer is an online IDE that supports, among many other languages, Google Carbon. You can compile, build and run tiny programs, and compare execution times of various languages against Google Carbon.

While naming its newest language, Google developers may have thought:

Carbon powers the planet. It must be credited for it. It is also the time we allow it to rest.

Following that line of thinking, Google Carbon would not just aim to remain a memory-safe C++ replacement but also an extremely performant one that minimises software carbon footprint.

Only stellar performance could justify overcoming the inertia involved in replacing tested and performant C++ codebase, mostly written by programmers spread across the entire history of programming.

It would be desirable that the programming community embraces Google Carbon with controlled enthusiasm and pragmatic time + money investment, given that it’s quite early in its development cycle.

In any case, it is an endeavour in the right direction. Witnessing the rugged, old programming language morphing into something modern and publicly built by a highly visible team, the programming community has only to gain.

News Credit

%d bloggers like this: