The "slow" isn't the performance of the application, but rather the ability to make changes to the language.

As it is, Google can't make changes to C++ that it wants in a timely manner (if at all). Having a C++g edition where there are slight changes to the language for the Google flavor rather than the latest standard makes things even worse.

From Google's perspective, the same can be said of Rust.

What Google does see is Swift where there are significant evolutionary changes to the language over the time.

So, Google has created their own language to fit into a similar space as C++ and allows them to make changes to the language at a much more rapid pace than the C++ standards committee would have.

My crystal ball says "this language will diverge further and further from where it started as Google changes it to solve Google Problems."

This shouldn't be a "Oh! Neat! Everyone start coding in Carbon - it's the next C++!" Yes, it's interesting in that there are some interesting ideas in it and refinement of ideas that aren't practical elsewhere. However, this is a language created to solve Google's problems - not the world's.

I meant slow as in the time it takes for the committees approval.

What exactly does this language solve in Google’s problem domain that can’t be enforced through guidelines?

Rather than enforcing the style guide ( https://google.github.io/styleguide/cppguide.html ) through code reviews and code review tools, the language itself encourages the developer to write better code than they would have if writing C++.

The Google C++ style guide is longer than the Carbon language design (though I will note a large number of sections that are "TODO").

(working from guesswork here)

Given the codebase that Google currently has in C++, the amount of effort to continue enforcing those style guides through human "this needs to change before I can approve it" to (in Google's eyes) more reasonable code with Carbon ultimately results in less developer time being spent reviewing style guide issues. At that scale, this may become a significant savings even when taking into account creating a new language.

It’s likely smaller than the style guide because it was just introduced. Either way that’s such a loose comparison.

I’m aware a language that enforces better coding styles is more efficient, I’m asking how and why does Carbon do this.

It has been a long time since I did work in C++, and I recall a number of foot-guns in the language.

Reading the design document for Carbon and looking at the samples, it appears that many of these are not as easy to access.

Things such as "not using the preprocessor for meta programming" by itself is a significant advantage.

While I intend to learn more Rust, compatibility with existing code is a big reason why I'm paying attention to Zig. It's not yet 1.0 and it's closer to C than C++.

However, because it's meant to compile and interop with both C and C++, I'm hopeful that it'll be an easier switch for more projects. It doesn't provide the safety checks that safe Rust does, but safe Rust requires a rewrite IIUC.

I haven't used Rust much, but based on everything I've read it seems like if you need a better alternative to C or C++...Rust is pretty much the answer. Is that not accurate?

This comment and parent comment don't appear to have read the article. It's specifically targetting C++ compatibility, that means compatible threading model, memory model, ABI, type system, ...

Rust has none of these. For every line of Rust code in the world, there are likely 10e3 - 100e3 lines of C++. You can either label it all "legacy code" and pretend your employer has the budget or time to rewrite it all, or you can find something in between writing new "legacy code", or throwing away your (for a company like Google) absolutely huge investment.

FWIW projects that build for interoperability have a much higher chance of long term success than those that don't. This is true for everything in software, not just programming languages. For this reason alone you can't easily compare Carbon and Rust. Carbon sounds something a little closer to Vala (C compatibility) than anything like Rust

Google rewrites a lot of their software components from scratch every few years, at least according to section 2.11 of this paper: https://arxiv.org/pdf/1702.01715.pdf

I only run one team, but this is not my experience at Google whatsoever. Some stuff gets rewritten but this is not planned and is largely due to catastrophic changes in requirements or very bad initial designs.

You didn't appear to read my comment, I'm talking about compatibility with Rust and all these other look alike languages.

Also your Vala comparison would imply this language compiles to C++.

If they manage to make Carbon highly compatible with C++ (which is one of the design goals IIUC), then a C++/Rust compatibility layer should work fine with Carbon/Rust, or am I missing something?

That's a big "if" of course, and time will tell whether they manage to pull it off, but at least that seems to be where they want to go.

Rust is already in production, I don’t think they take a different approach to compatibility.

The same approach to compatibility with C++? Can you use Rust as successor language in a C++ codebase, just like Typescript in a Javascript codebase? From my (limited) understanding that's not as straightforward, and other sources online seem to agree with this (e.g. see comments in https://old.reddit.com/r/rust/comments/w2tygg/carbon_languag...).

The way I see it, Carbon has C++ compatibility as a requirement, adding as much safety, performance etc. as possible on top, while Rust seems to start from a safe-by-default approach and building its way from there.

From experience binding some Rust and C++ is not a trivial task. The introduction of Rust ownership and lifetimes alone means this always involves new design, even just to provide something approaching a 1:1 mapping to an existing API. True 1:1 mappings at least in my experience simply aren't possible, there is always some contortion required to reduce the freedom+unsafety exported by C

My mistake. Thank you for clarifying.

> if you need a better alternative to C or C++...Rust is pretty much the answer. Is that not accurate?

If the thing(s) that you're looking to "better" about C++ are its atrocious compile times and/or the C++ culture's even more atrocious shared aesthetics, then the answer is "no".

I have only dabbled in Rust but I found the interop situation to be less than ideal. Plenty of C/C++ libraries either don't have Rust wrappers at all or have been long abandoned.

I like the ability of Carbon to seamlessly integrate with existing C/C++ code and libraries.

We have more than 5 C++-alike languages that are crawling around already. In some ways they have portions of mutual compatibility. But in practice this only matters if you decide to embrace the complexity of five different programming languages when building your software. It's already somewhat challenging for projects to manage assembly, C, and C++.

assembly, C, and C++ is one of the most "standard" things to do out there. Unless you are talking about non-standard toolchains of course (everything that isn't clang or gcc based). C++ is mostly a superset of C so all the C++ compilers out there have pure C modes, and assembly integrates really well into C and C++ build systems.

We're just gonna add a 6th standard to end all standards.

so basically Google C