4 ms·

> Complains C++ evolution is too slow due to enforced standardizations by committee. > Introduces yet another non standardized, corporately backed Rust look-al

> Complains C++ evolution is too slow due to enforced standardizations by committee. > Introduces yet another non standardized, corporately backed Rust look-alike language. What's gonna happen when we have 5 of these things crawling around, are they going to be compatible with each other?

htrp 4y ago
so basically Google C
rvnx 4y ago
We're just gonna add a 6th standard to end all standards.
brightball 4y ago
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?
- baobob 4y ago
  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
  - pipeline_peak 4y ago
    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++.
    - hiq 4y ago
      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.
      - pipeline_peak 4y ago
        Rust is already in production, I don’t think they take a different approach to compatibility.
        hiq 4y ago
        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_language_an_experimental_successor_to_c/ 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.
        baobob 4y ago
        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
- threeseed 4y ago
  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.
- pwdisswordfish9 4y ago
  > 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".
wyldfire 4y ago
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++.
- est31 4y ago
  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.
epicide 4y ago
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.
- deleted 4y ago
  [deleted]
shagie 4y ago
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.
- pipeline_peak 4y ago
  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?
  - shagie 4y ago
    Rather than enforcing the style guide ( https://google.github.io/styleguide/cppguide.html 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.

htrp 4y ago

so basically Google C

rvnx 4y ago

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

brightball 4y ago

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?

baobob 4y ago
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
- pipeline_peak 4y ago
  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++.
  - hiq 4y ago
    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.
    - pipeline_peak 4y ago
      Rust is already in production, I don’t think they take a different approach to compatibility.
      - hiq 4y ago
        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_language_an_experimental_successor_to_c/ 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.
      - baobob 4y ago
        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
threeseed 4y ago
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.
pwdisswordfish9 4y ago
> 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".

wyldfire 4y ago

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++.

est31 4y ago
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.

epicide 4y ago

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.

deleted 4y ago
[deleted]

shagie 4y ago

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.

pipeline_peak 4y ago
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?
- shagie 4y ago
  Rather than enforcing the style guide ( https://google.github.io/styleguide/cppguide.html 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.