[nemetroid]

The "Dart plan" vs "TypeScript plan" comparison is shown at 1:33:50 in the talk:

> "Dart plan" - Competitive/successor 10x improvement

> New creation

> Limited interop, relies on wrapping/marshaling/thunking...

> Competes with standard (e.g., different modules, different generic constraints)

> Evolves independently of standards committee - far fewer design constraints

> Needs to bootstrap a new ecosystem

> "Typescript plan" - Cooperative/compatible 10x improvement

> Every .js file is a valid .ts file, add 1 class and see benefit

> Lowers to standard .js, 100% seamless compat with all JS libraries

> Cooperates with the standards committee (ECMAScript)

> Brings evolution proposals to standards committee

> Leverages entire existing ecosystem - works with all JS implementations & tools

Carbon is an example of the "Dart plan". Some quotes from Carbon's "Interoperability philosophy and goals" page (my emphasis):

> The C++ interoperability layer of Carbon allows a subset of C++ APIs to be accessed from Carbon code, and similarly a subset of Carbon APIs to be accessed from C++ code.

> The result is that it will often be reasonable to directly expose a C++ data structure to Carbon without converting it to a "native" or "idiomatic" Carbon data structure. Although interfaces may differ, a trivial adapter wrapper should be sufficient.

> There should be support for most idiomatic usage of advanced C++ features. A few examples are templates, overload sets, attributes and ADL.

> Non-goals

> Never require bridge code

> Support for C++ exceptions without bridge code

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

[chandlerc1024]

FWIW, I disagree about Carbon following the Dart plan (Carbon lead here).

Carbon is following a plan much more analogous to Kotlin -- we even say that on our site very explicitly.

The "subset" of C++ APIs you emphasize is only about there existing some long-tail esoteric parts of C++ that may be used rarely enough to not worry about. Everything that people use we'll need to support here. We think about interop constantly and are designing it into every aspect of the language.

[nemetroid]

Sure, there might be other interop stories that are a better fit, and Dart is a pretty unflattering comparison (perhaps chosen intentionally). But within Herb's dichotomy, I think Carbon falls into the "Dart" category, since the "Typescript" category is rather narrow.

[chandlerc1024]

If you're going to create a dichotomy between two languages, I think we're dramatically closer to TypeScript.

The whole point of Carbon is to integrate into and re-use an existing ecosystem of software written in C++. It's as far from the Dart approach as it can get without literally being a TypeScript style approach.

Ultimately, this dichotomy doesn't help discuss Carbon. I think it is useful for looking at Rust (until/unless Crubit or something similar radically changes its interop story), Go, and many other languages. But not Carbon IMO. It loses all of the important nuance. And there are important and meaningful differences from TypeScript's approach that we've talked about since announcing Carbon, but they don't make it anything like Dart's strategy.

[jonex]

The dichotomy is relevant if you are of the opinion that some of the foundational design choices of Carbon makes it less viable as a C++ successor based on the similarity of those choices to other projects that were struggling due to this. The talk is arguing for the validity of the construct with various examples, not just Dart.

The construct can be useful without being the end-all answer to what should be done and I would definitely advice you to watch the full talk if you haven't yet. And the consider how each point may apply or not apply to Carbon. Don't just dismiss it on the notion that Carbon is different from Dart.

Actually, I'd encourage you to reach out to Herb Sutter and ideally meet up in person to discuss the matter. Your goals are aligned in many ways and while you have different approaches a lot of good can come out of sharing ideas.