Of course, some would say that this isn't difficult as almost anything would be better! Is C++ in need of a replacement? Yes it is - but the problem is that there is a lot of it about.

AsI have said before, C++ was a good idea that simply grew beyond the reasonable. Today there are just too many ways of doing anything with it and too many ways to make C++ look like your own personal language.

CC Robert M. Lavinsky

Now a group of Google engineers have got together to see if their latest project, Carbon, can do something about the problem.

Google has a reputation for inventing, or just making use of, languages that are extensions to existing languages. Dart for JavaScript, Go for C and Kotlin for Java. Of course, we have Rust as a proposed alternative to C and C++, but this isn't really an extension language - it's more a complete, let's-start-over, language. Carbon is trying to be like Rust while remaining compatible with the C++ world. Its Github page states;

• Performance matching C++ using LLVM, with low-level access to bits and addresses
• Interoperate with your existing C++ code, from inheritance to templates
• Fast and scalable builds that work with your existing C++ build systems

It is claimed that Carbon is needed because incrementally improving C++ just isn't possible any more due to the historical baggage that you simply cannot get rid of. I personally would go further and suggest the the incremental "improvements" to C++ are part of the reason it is, in practice, such a sprawling language.

One thing I find interesting about the Carbon project is the statement:

Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should. 

Does this suggest that the team thinks that the task of staying compatible with C++ is such a constraint that Carbon cannot better these existing language - or is it just false modesty?

Here is a sample of Carbon:

// Carbon:
package Geometry api;
import Math;
class Circle {
  var r: f32;
}
fn PrintTotalArea(circles: Slice(Circle)) {
  var area: f32 = 0;
  for (c: Circle in circles) {
    area += Math.Pi * c.r * c.r;
  }
  Print("Total area: {0}", area);
}
fn Main() -> i32 {
  // A dynamically sized array, like `std::vector`.
  var circles: Array(Circle) = ({.r = 1.0}, {.r = 2.0});
  // Implicitly constructs `Slice` from `Array`.
  PrintTotalArea(circles);
  return 0;
}

I haven't had enough time to get to grips with the language to be confident to provide my own example, but this does give you the flavor of something that looks C++-like, but with modern elements. Notice that the for loop is a for in loop and not the baroque C/C++ style for loop - the "semi-semi", so named because of the two semicolons in its syntax.  It will be interesting to see if  leaving out the semi-semi can be maintained despite the obvious requests that will be forthcoming for it to be reinstated.

There are also examples of working with C++ and Carbon mixed programs and these seem straightforward.

The two areas where I start to worry are generics and memory safety. I worry about generics because to date I've not seen an implementation of generics that gave back more than it took. The Carbon approach looks clean, but it all depends on the finer detail which takes time to figure out.

My worry about memory safety is performance. The GitHub page states:

• Tracking uninitialized states better, increased enforcement of initialization, and systematically providing hardening against initialization bugs when desired.
• Designing fundamental APIs and idioms to support dynamic bounds checks in debug and hardened builds.
• Having a default debug build mode that is both cheaper and more comprehensive than existing C++ build modes even when combined with Address Sanitizer.

This is too vague to comment on, but its heart is in the right place.

Will Carbon ignite?

Who knows as it isn't the first attempt at replacing or extending  C++.

I also feel compelled to ask why is it that Google names languages so that you can't find them using a search engine - Go and Carbon turn up lots of non-programming related topics. Do we really have to call it Carbonlang in practice?

We will have to see if some time and development pressure manages to turn Carbon into the diamond we are looking for.

More Information

https://github.com/carbon-language/carbon-lang

Related Articles

Google Releases Logic Programming Language

Google spawns yet another language - Dart

Why Is Go Good?

A Decade of Go - Google's Systems Language

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.