> 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.
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.
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.
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.
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.
No, it says "No one else has tried the TypeScript plan for C++ yet". Which is true; Carbon isn't a compiler/transpiler to C++, it's a whole new language, albeit one with strong C++ interop.
"Strong C++ interop" can also be achieved via libraries from an existing language, as with the Rust "crates" cxx, autocxx, crubit. So the jury is still out as to whether an entirely different language, namely Carbon, will be useful. OTOH, cppfront can be seamlessly transpiled to C++ on a file-by-file basis which can also be a desirable feature wrt. incremental adoption.
My understanding is that none of those crates support both instantiating C++ templates from Rust and instantiating Rust generic functions from C++, let alone stuff like implementing a Rust trait with a C++ object from C++ code. These things would be _very_ difficult to do because of the impedance mismatch between the languages, and so there's space for a language with "even stronger" interop.
Carbon is disappointing and feels like a missed opportunity. It feels more like a syntax refresh. C/C++ desperately need a safety overhaul. I work in the embedded functional safety space. Rust has shown it can be done. Not having lifetime/borrowing support or something that achieves the same thing from the start gives the impression nothing has been learned in the last decade.
Google claims that Carbon is the future internally at Google for a safer C++, and Google never approves Rust for internal usage. Then I see multiple public announcements of Google rewriting something in Rust (such as the recent Binder rewrite). I'm quite confused.
Completly false, the Carbon project folks are quite clear it is an experimental language, and anyone not having legacy C++ codebases should use Rust, or a manage language, if their requirements can cope with automatic memory management.
Android, ChromeOS and Fuschia already use Rust, and Chrome is in the process of getting the first Rust libraries integrated.
For the most part, Rust projects at Google tend to be things that are relatively self-isolated (like the Binder rewrite). Google has a huge monorepo with tens of millions of lines of C++ code, much of which is highly interlinked and interdependent. The goal of Carbon is to help move that code to a simpler and safer programming model.
> "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...