Carbon - a new experimental successor to C++ by Google

[rahmansunbeam]

Frustrated by the slow evolution of the C++, Google engineers have launched a new “experimental” open source programming language, called Carbon, as a possible successor to the venerable but aging C++. The language was recently unveiled at the CPP North conference in Toronto by Google developer Chandler Carruth.

Why Is It Difficult To Incrementally Evolve C++?

Carruth mentioned a few points that can be summarized in two areas: Language and Bureaucracy

Language

• Technical debt. Necessary choices that made C++ great are becoming a burden. C++ accumulated decades of technical debt.
• Prioritization of backward compatibility. More and more features have been added, rather than removed or replaced. While backward compatibility is important, it comes at a cost. It adds and prevents fixing the technical debt.

Governance

• Processes. The process to improve C++ goes through a bureaucratic committee approach that prioritizes standardization above design.
• Limited access. Access to the committee and standard is restricted and expensive.
• Interests of the few. While some nations and companies are represented, many other stakeholders are not.
• Lengthy decision process. Decisions can take years, or not reach any definitive conclusion.

You can read more about the difficulties to improve C++ on the GitHub page.

Carbon Programming Language: An Experimental Successor To C++

Given the context, it seems reasonable to think of a new purpose-driven language that builds on the six goals for C++ and adds one more:

• Performance-critical software
• Software and language evolution
• Code that is easy to read, understand, and write
• Practical safety and testing mechanisms
• Fast and scalable development
• Modern OS platforms, hardware architectures, and environments
• Interoperability with and migration from existing C++ code

Syntax

Among the presented features, it is worth mentioning:

• Introducer keywords: fn for function, var for variable declarations
• Function input parameters are read-only values
• Pointers provide indirect access and mutation
• Expressions to name type
• The namespace at the root is always local
• Public members by default. The reasoning seems to be that since you will mostly read the public functions in your API, it makes sense to expose them.
• Type checking generics

Here is an example of Carbon

// Carbon:

package Geometry api; // local namespace
import Math; // library import

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);
}

"Hello world" in Carbon

package sample api;

fn Main() - > i32 {
    Print("Hello, world!");
    return 0;
}

Carbon explorer

Carbon getting started

Vim/ Neovim extension

Carbon

Souces -

https://levelup.gitconnected.com/googles-carbon-might-replace-c-7b634b465f51
https://www.c-sharpcorner.com/article/introducing-carbon-googles-new-programming-language/

I am more leaning towards Rust which originally backed by Mozilla foundation. I haven't found any performance comparison among C++, Rust and the new Carbon but here is a good discussion.

Edited August 25, 2022 by rahmansunbeam

[Lurker]

interesting in learning Python, wish me luck 

[rahmansunbeam]

22 hours ago, Lurker said:

interesting in learning Python, wish me luck 

👍