Will Carbon, developed after Google, really replace C++?

[CSDN editor’s note] Can Carbon really become a substitute for C++? For now we can only guess, but don’t forget the birth of languages ​​like Swift or Kotlin.

Original link: https://ift.tt/r0XqRfS

Unauthorized reprinting is prohibited!

Author | Manuel Rubio Translator | Crescent Moon

Produced | CSDN (ID: CSDNnews)

At the CppNorth conference in 2022, Chandler Carruth delivered a keynote speech titled: Carbon Language: An experimental successor to C++, which mentioned a new open source development language called “Carbon”, which claims to be the successor of C++ By.

But why do we need a successor to C++? Where did this idea come from?

On the last day of CppCon 2019, Chandler Carruth and Titus Winters gave an amazing talk about What is C++? In my opinion, one of the most interesting ideas conveyed by the speech was, “Languages ​​are tools, and we must use the right tools for the job.”

At the end of the conversation, they came up with different proposals aimed at solving some common problems faced by C++ developers, including:

• Performance-focused software. We need to consider not only speed, but also latency, memory utilization, battery utilization, etc.

• The evolution of software, the evolution of language. C++ was written decades ago, language designers make mistakes, and we should improve and upgrade C++ based on most current language changes – however, there are always people in the community who are against change.

• Simple and easy to read, understand and write. I think this quote from John Carmack sums it up well: “One of the great things about raw C is that most advanced developers are capable of writing their own C compilers, and knowing the tools you use is invaluable. But if it is a C++ compiler, I need a lot of time to learn to write it.”

• Safety and testing. Safer APIs, cheap security mitigations, and a comprehensive testing approach using continuous integration unit and integration tests. All untrusted inputs are continuously fuzzed, and all tests use inspection build modes (sanitizer, assertions, etc.).

• Fast and scalable development, essentially modules.

• hardware, operating system, environment. Define what we are committed to supporting and continue to advance in a predictable manner. We don’t intentionally break a 20-year-old platform, but we don’t continue to support it either.

Can we improve C++ or use another language?

At CppNorth 2022, Carruth gave us information on this. He starts by referring to the suggestions from the previous talk and discusses why C++ cannot implement them. The main problem is that C++ accumulated decades of technical debt during which time the community prioritized backwards compatibility and thus failed to fix the technical debt.

So, can an existing language be used instead of C++? Garbage-collected languages ​​are great, but we won’t consider them because they come at a performance cost, and most C++ developers don’t think they want to compromise on that.

The Rust programming language is a good choice because it is memory safe and very suitable as a replacement for low-level languages, but see the substitution relationship below, Rust cannot actually replace C++:

• C –> C++

• JavaScript –> TypeScript

• Objective C –> Swift

• Java –> Kotlin

• C++ –> Rust?

Rust is a language that works well and is highly recommended if you are starting a new project. But if you need to migrate the C++ ecosystem to Rust with all kinds of deep dependencies, it will be a very difficult task. We do not recommend this practice.

What we need is a “successor”. Here “successor” refers to a language built within an existing ecosystem, without building a new language, which provides interoperability and is easy to learn and adopt, and ideally, all auxiliary tools can also continue provide support. Essentially, a “successor” is a superset of its parent language.

What is the Carbon programming language?

After discussing the problems with C++, Carruth posed a question: what’s next? After discussing why we can’t improve C++, why we can’t use Go or other garbage-collected languages, and why we can’t use Rust (or other low-level languages), Carruth argues that we need to create a “successor” to C++: Carbon .

Carbon took the suggestion to improve C++ and incorporated it into the language’s design goals, while they also took care of a new key goal, the most important one: interoperability and migration with existing C++ code.

According to the information on the official website, the reasons for the creation of the Carbon language are as follows:

“Fundamentally, Carbon is a successor language rather than attempting to evolve C++ incrementally. Carbon will be designed around interoperability with C++ and mass adoption and migration of existing C++ codebases and developers. […] With this approach, we can build software on top of the existing C++ ecosystem and continue to support existing investments, code bases, and developer communities.”

Will Go or Dart disappear?

Carruth is technical director of programming languages ​​and software foundations at Google, and the Carbon language project started at Google, so there are concerns that Golang and even Dart support may weaken. However, Google is a big company and they need to develop software through different platforms and different projects. This means, they need different languages ​​for different jobs.

Google’s production environment uses Go for some services (dl.google.com’s download server), but as Carruth said, the migration of large C++ projects is difficult and impossible.

Dart is a language built on top of JavaScript and other languages, and its mission is to become the main language of the Flutter project, solving the problem of creating applications across platforms. Since Flutter does not support C++, Carbon is basically useless in this environment, so the Dart language will not be affected.

How to use this new language?

During the Core C++ conference in 2022, Jon Ross-Perkins (Senior Software Engineer at Google with two years of experience with the Carbon language) talked about the syntax and tradeoffs of the Carbon language.

First, he emphasized that the project is still experimental at the moment, but I wanted to take a first peek at the ecosystem through tools. Ross-Perking mentioned the following tools for the project:

• translater. Needless to say, the compilation of the code is very important.

• formatter. Format the code properly.

• Language automatic upgrade. Tidy up our code at a higher level than formatters.

• IDE and LSP support.

• Refactoring support.

• package manager.

When it comes to writing code, it’s important to keep the context of development intact, but do we need to keep that much information? To simplify the context, Carbon provides specific reserved words so that tooling is easier to use and code is more readable. These reserved words include:

• var: used to declare variables.

• class: Used to define classes.

• fn: Used to define functions.

• interface : Used to define an interface.

• let: Used to declare constants.

Examples are as follows:

 var radius: Printer(Circle); class Circle class Printer(template t:! Type) fn Draw() interface Shape let Pi: f32

I think we can go straight to the details of the syntax and the code examples. But before looking at the code, I need to say that the language is still experimental, and like most experiments, it may evolve or die. But as things stand, it’s a promising project.

Regarding the syntax, since the first version has not been officially released, the actual code may differ from this in the future. If you want to see the latest development of the language, you can check out the design document (https://ift.tt/suUGlCz), which contains the designers and developers Suggestions and changes contributed by people.

 import Math; // Returns the smallest factor of `n` > 1, and // whether `n` itself is prime. fn SmallestFactor(n: i32) -> (i32, bool) { let limit: i32 = Math.Sqrt(n) as i32; var i: i32 = 2; while (i <= limit) { let remainder: i32 = n % i; if (remainder == 0) { Carbon.Print("{0} is a factor of {1}", i, n); return (i, false); } if (i == 2) { i = 3; } else { // Skip even numbers once we get past `2`. i += 2; } } return (n, true); }

The above code uses two different functions. It appears that the functions in the Carbon package are imported by default, while the Math package needs to be imported in order to be used.

We also use two constants ( let ). The first limit is constant throughout the function, while the second remainder is constant within the scope of the while loop, creating and binding a value for each iteration. The constant limit also declares a different type than the one returned by the Math.sqrt function, but it is converted using as i32.

We see that a tuple is defined in return. Based on this technique, the function returns two values ​​instead of one. Languages ​​such as Python, Erlang or Elixir also use this data type. This way, we can handle a set of values ​​differently.

looking to the future

Carbon is currently an experimental project, but you can check out its roadmap for recent developments. Through the aforementioned documents, we can see that Carbon’s expected release time (stop experimentation) was originally scheduled for 2023, then changed to 2024, and now it has been launched to 2025-2026. However, we can see that Carbon is developing rapidly and not stopping.

Can Carbon really be a replacement for C++? For now we can only guess, but don’t forget the birth of languages ​​like Swift or Kotlin. At the beginning of the text, we listed a number of proposals for C++, and I believe that most large companies that want to solve these problems will accept and adopt Carbon.

The text and pictures in this article are from CSDN