People like to always talk about Carbon like that, yet the team is the first to point out anyone that can use something else, should.

Carbon is an experiment, that they aren't sure how it is going to work out in first place.

> "If you can use Rust, ignore Carbon"

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

> "We want to better understand whether we can build a language that meets our successor language criteria, and whether the resulting language can gather a critical mass of interest within the larger C++ industry and communit"

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

> Herb side that proposes minimal changes

Herb is developing a whole second syntax, I wouldn't call that minimal changes. And probably the only way to evolve the language at this point, because like you said Sean is introducing a different language entirely, so its not C++ at that point.

I really like some of Herb's ideas,but it seems less and less likely they'll ever be added to C++

Have you seen some of his recent talks? Lots of underpinnings of cppfront have been added or are in committy.

He compares it to the JS/TS relationship.

It's not really a valid comparison though. cppfront is a different language that just happens to be compatible with C++. ts/js is were ts is just js with types. You can comment out the types and it just runs. cppfront's language you'll actually have to re-write the code to get it to compile in C++

typescript

    function add(a: number, b: number): number { return a + b };

javascript

    function add(a/*: number*/, b/*: number*/)/*: number*/ { return a + b };

cppfront

    add: (a: float, b: float): float = { a + b; }

cpp

    float add(float a, float b) { return a + b; }

Do you realize that the Typescript example contains strictly more information than the Javascript one (namely, declarations for the type of three things) and is therefore more complex to compile, while the two C++ examples are semantically identical (the last expression in the function is returned implicitly without having to write "return") and the new syntax is easier to parse?

There are several semantic differences between Cpp1 and Cpp2. Cpp2 moves from last use, which is the biggest one. In a contrived example, that could result in a "hello world" changing to "goodbye world" or any other arbitrary behavior change you want to demonstrate. Cpp2 also doesn't require you to order functions and types or declare prototypes, which means partial template specializations and function overloads can produce similar changes when migrating from Cpp1 to Cpp2.

I've written a little demo here: https://godbolt.org/z/xn1eqd5zb

You can see where CPPFront inserts a `cpp2::move` call automatically, and how that differs from a superficially equivalent Cpp1 function.

yes, of course. That's not my point. My point is TypeScript succeeds because it's just JavaScript with types. It's not a new language. cppfront is an entirely new language so it's arguably going to have a tougher time. Being an entirely new language, it is not analogous to typescript

> ts/js is were ts is just js with types. You can comment out the types and it just runs.

Is this true in the general case? I thought there were typescript features that didn't have direct JavaScript alternatives, for example enums.

Enums and namespaces are the only runtime features of TypeScript.

So, yes, you can't just strip types, but it's close.

Is there a comprehensive list of such incompatibilities documented somewhere?

That's not the same.

That guarantees that the types do not determine the output (e.g. no const enums), not that you can "strip" types to get the same output.

Not that I'm aware of.

Decorators would be another example. (Though they have always been marked experimental.)

And of course JSX, but that's not a TypeScript invention.

Nope, that is mostly sales pitch, the only thing added thus far has been the spaceship operator.

He also sells the language differently from any other language that also compiles to native via C++, like Eiffel and Nim among others, due to conflict of interest to have WG21 chair propose yet another take on C++.

> He compares it to the JS/TS relationship.

OP is right, TypeScript is a whole new syntax, and it's shtick is that it can be transpiled into JavaScript.

Carbon isn't currently memory safe, but Chandler Carruth has made it clear that every security expert he talked to says the same thing: memory safety is a requirement for security.

He at least claims that Carbon will have memory safety features such as borrow checking down the line. I guess we'll see.

It’s worrying to me that Carbon separates data races and memory safety as two distinct things when data races can easily cause both spatial and temporal memory safety issues. Similarly, type safety, can also cause spatial issues (e.g. many kernel exploits in Darwin were a result of causing type confusion for the SLAB allocator resulting in an exploitable memory safety issue).

The entire philosophy errs too much in the direction of “being reasonable” and “pragmatic” while getting fundamental things wrong.

> Over time, safety should evolve using a hybrid compile-time and runtime safety approach to eventually provide a similar level of safety to a language that puts more emphasis on guaranteed safety, such as Rust. However, while Carbon may encourage developers to modify code in support of more efficient safety checks, it will remain important to improve the safety of code for developers who cannot invest into safety-specific code modifications.

That’s really just paying lip service to Rust without recognizing that the key insight is that optional memory safety isn’t memory safety.

It is kind of neat just how much Rust has managed to disrupt the C++ ecosystem and dislodge its position.

In principle data races can cause memory safety issues, but they are usually very hard to exploit.

Java guarantees VM integrity in the face of data races, while for example many races are UB in theory and in practice in Go. Both are considered safe languages.

Sometimes pragmatism is in fact a valid goal.

edit: from a practical point of view I don't know how realistic is to retrofit memory safety to a language that lacks it.

Golang is very much not considered "safe" from data races.

I explicitly said it isn't. It is still considered a broadly memory safe language.

An interesting claim to make. Do you have evidence to support that position?

I could just as easily offer a valid counter analysis to explain the data. They’re “hard” just because there’s so many easier avenues so attackers just often don’t bother not because they’re intrinsically unlikely. Let’s say you’re successful in eliminating temporal & spatial classes of failures completely (even Rust proponents do not claim this). They’ll focus on data races and type confusion next.

> Both are considered safe languages

Go is considered a memory safe language today because C and C++ are the anchor that we compare against and we have overwhelming evidence against it (but it’s also where a huge amount of value is in terms of the systems they underpin). In 50 years time, it’s not inconceivable that a lot of the languages may lose their memory safety designation if their runtimes continue to be written to C/C++ (Java) and/or data races remain unaddressed at the language level (Go) and we have overwhelming evidence that exploits just moved on to architectural defects in those languages.

It may raise costs of exploits but cybercrime is estimated to be a 10T dollar market next year so there’s clearly a lot of money to put towards exploits.

> from a practical point of view I don't know how realistic is to retrofit memory safety to a language that lacks it

I think letting people evolve into a more memory safe situation is good. I think doing it partially instead of tackling memory safety in all its forms is just asking for trouble - your attackers will be able to develop exploits more quickly than you are able to update all existing code to more secure language features.

(Carbon lang dev here.)

Carbon is intended to be memory safe! (Not sure whether you intended to write a double negative there.) There are a few reasons that might not be clear:

* Carbon has relatively few people working on it. We currently are prioritizing work on the compiler at the moment, and don't yet have the bandwidth to also work on the safety design.

* As part of our migration-from-C++ story, where we expect code to transition C++ -> unsafe Carbon -> safe Carbon, we plan on supporting unsafe Carbon code with reasonable ergonomics.

* Carbon's original focus was on evolvability, and didn't focus on safety specifically. Since then it has become clear that memory safety is a requirement for Carbon's success, and will be our first test of those evolvability goals. Talks like https://www.youtube.com/watch?v=1ZTJ9omXOQ0 better reflect more recent plans around this topic.

Not super familiar with Carbon but .. what's the elevator pitch for porting my C++ to unsafe Carbon? Can it be done with an automated refactoring tool or something?

I feel like if I'm gonna go through the whole nightmare of a code port I should get something for it as opposed to just relying on interop

The idea is that it is an incremental process. By default you should be able to make minimal changes to your code and it should mostly just work. Over time you can use features that more tightly couple you to Carbon, such as memory safety. Google's motivation is supporting its massive C++ codebase while providing a path for memory safety and other features. If your use case does not closely mirror that of Google's, namely, that you have 10+ year old code you intend, and have, to maintain, Carbon probably doesn't make sense for you and that is generally made pretty clear for anyone interested in the language.

Thanks for the correction, I appreciate it!

The double negative was not intended :)