5 ms·

The article claims nobody’s tried a language natively compatible with C++, but that’s the approach that Google’s Carbon is taking: https://github.com/carbon-la

The article claims nobody’s tried a language natively compatible with C++, but that’s the approach that Google’s Carbon is taking: https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang

gpderetta 3y ago
And Circle and cppfront. Edit: of course this is about cppfront :)
- BalinKing 3y ago
  Indeed, I think the article is about cppfront.
whoiscroberts 3y ago
Carbon is on my list of things to experiment with.
iris2004 3y ago
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.
scaredginger 3y ago
> Note that Carbon is not ready to use
logicchains 3y ago
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.
- pjmlp 3y ago
  That is completely false, as it ignores Circle and Sean Baxter's efforts.
  - IAmLiterallyAB 3y ago
    When Sean is willing to release the source, I'll start paying attention. Until then, it's just a tech demo.
    - pjmlp 3y ago
      I guess many C and C++ compilers are tech demos as well, including some forks from GCC and clang.
- zozbot234 3y ago
  "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.
  - HALtheWise 3y ago
    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.
bitschubser_ 3y ago
This is also a design goal for swift, afaik…
- superb_dev 3y ago
  I think at this point Swift/C++ interop is pretty good too (anecdotally)
nemetroid 3y ago
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/docs/design/interoperability/philosophy_and_goals.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...
- chandlerc1024 3y ago
  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 3y ago
    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.
bdd8f1df777b 3y ago
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.
- bananapub 3y ago
  > Google never approves Rust for internal usage. deeply incorrect.
  - tialaramex 3y ago
    Also you'd have to wonder what https://google.github.io/comprehensive-rust/ https://google.github.io/comprehensive-rust/ is for. Like, if Google "never approves" why are they designing a course to teach this, and paying outsider trainers to teach their staff ?
- eklitzke 3y ago
  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.
- pjmlp 3y ago
  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.

gpderetta 3y ago

And Circle and cppfront. Edit: of course this is about cppfront :)

BalinKing 3y ago
Indeed, I think the article is about cppfront.

whoiscroberts 3y ago

Carbon is on my list of things to experiment with.

iris2004 3y ago

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.

scaredginger 3y ago

> Note that Carbon is not ready to use

logicchains 3y ago

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.

pjmlp 3y ago
That is completely false, as it ignores Circle and Sean Baxter's efforts.
- IAmLiterallyAB 3y ago
  When Sean is willing to release the source, I'll start paying attention. Until then, it's just a tech demo.
  - pjmlp 3y ago
    I guess many C and C++ compilers are tech demos as well, including some forks from GCC and clang.
zozbot234 3y ago
"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.
- HALtheWise 3y ago
  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.

bitschubser_ 3y ago

This is also a design goal for swift, afaik…

superb_dev 3y ago
I think at this point Swift/C++ interop is pretty good too (anecdotally)

nemetroid 3y ago

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/docs/design/interoperability/philosophy_and_goals.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...

chandlerc1024 3y ago
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 3y ago
  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.

bdd8f1df777b 3y ago

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.

bananapub 3y ago
> Google never approves Rust for internal usage. deeply incorrect.
- tialaramex 3y ago
  Also you'd have to wonder what https://google.github.io/comprehensive-rust/ https://google.github.io/comprehensive-rust/ is for. Like, if Google "never approves" why are they designing a course to teach this, and paying outsider trainers to teach their staff ?
eklitzke 3y ago
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.
pjmlp 3y ago
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.