7 ms·

I really think the most exciting feature of Carbon (indeed, it's justification for existence) is its backwards compatibility with C++, followed closely by it's

by bbkane 4y ago

I really think the most exciting feature of Carbon (indeed, it's justification for existence) is its backwards compatibility with C++, followed closely by it's more modern and flexible governance structure. Even the docs in the repo say you should avoid Carbon unless you have lots of C++ code you need to interact with.

deleted 4y ago
[deleted]
usrnm 4y ago
Some of the biggest problems with C++ come from its backwards compatibility with C. Yes, it wins you users in the short term, but it's a pain to support as both languages evolve
- olliej 4y ago
  The binary compatibility is the big deal. The other safe languages have explicitly taken the view the interop with C++ is bad, and so we should instead do interop with the significantly less safe C instead. The real killer is that the lack of any interaction with C++ means that you can’t do any real incremental adoption of one of those safe languages in any big security critical projects. Saying that the solution to C++ is to just not use it ignores the reality that C++ exists, and large projects in C++ exist. It doesn’t matter if you don’t like C++. The final problem with the safe languages - with the exception of swift - is that they are all hell bent on not providing even just basic ABI stability. It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface. So I can have two libraries both written in rust, and the entire safety of it is contingent on each library talking to the other through a C API.
  - staticassertion 4y ago
    > The other safe languages have explicitly taken the view the interop with C++ is bad I think it's more that interop with C++ is hard and ultimately a lot less valuable than interop with C, which is what the vast majority of languages use for FFI. > It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface. I don't see how that leads to "it doesn't matter"
    - __float 4y ago
      If you consider the context of Carbon (Google having a _lot_ of C++), solving for "interop with C++ is hard" might be considered worth the price. Whether that's true in practice...? I guess we'll need a few more years to tell.
      - staticassertion 4y ago
        Of course, that's why they're building it. They're solving a very specific, niche, hard problem. It would make no sense for other languages, which want to solve more general problems, to tackle C++ interop over C.
        olliej 4y ago
        I do think this is very much a google project specifically because they have a lot of C++ and recognize that there needs to be a path to a memory safe environment, and that is why this project exists. But I don't think the goal is inherently wrong, nor do I think it's niche - there is a lot of C++ in the world, and much of it would benefit from being memory safe. A lot of the largest projects and certainly many of the most heavily used software projects are written in C++. I think you'd agree that having them no longer be be trapped in a memory unsafety tarpit would be a Good Thing. Let's imagine someone came out with a magic C++ compiler that had 100% source and ABI compatibility and had no performance costs, but was completely memory safe - remember "magic". You'd obviously expect, if not demand, that every C++ project switch to that magic compiler. So let's imagine we're on a scale from 1 to 10, where 1 is the memory safety of current compilers and 10 is our magic clearly impossible one. Obviously every step we can go towards 10 is great, but is going to come with trade offs in adoption cost. So on another 1 to 10 scale where 1 is rewriting in some other random language (rust, etc) and 10 is your current compiler, then you want the new language to be as close to 10 as possible. One thing you could do is build all your code with ASAN or a similar mechanism, that would have low adoption cost, a dramatic improvement in runtime safety, but a huge performance cost (time for another 1 to 10 scale?). Carbon appears to be an attempt to design a language with a reasonably high score in all of the scales - no 10s, but mostly 7s or something. I personally think that there are things we could do to C++ that would make a meaningful improvement to safety without having the solution be "rewrite in other language", but I won't fault a project saying "we'll support incremental adoption" as their adoption path in exchange for stronger safety.
  - usrnm 4y ago
    > The other safe languages have explicitly taken the view the interop with C++ is bad It's not that it's inherently bad, it's just insanely difficult to do and, probably, isn't worth the pain. Carbon's approach to solving this problem includes embedding a custom C++ compiler as part of its toolchain, and at this point it's just the idea, who knows if they will be able to actually do it. > they are all hell bent on not providing even just basic ABI stability Right, the famous stable C++ ABI
    - mkoubaa 4y ago
      Interop with c++ is definitely inherently bad.
      - olliej 4y ago
        I get that this is kind of facetious, but don't you want things like your browser engine to be in a memory safe language?
    - olliej 4y ago
      ...yes? The C++ is absolutely ABI stable, and is described in excruciating detail, as demonstrated by all those C++ libraries, that you don't have to recompile for on every OS update. I suspect you're confusing when you make an ABI change, without changing the API, which is indeed an easy thing to do: You have to make sure that you only add members to the end of objects, however that exact constraint also applies to C.
      - KerrAvon 4y ago
        Fragile base class problem is solved, then? When did that happen?
        olliej 4y ago
        No, but that's also not relevant as C++ is ABI stable. I can take any C++ compiler, and I can compile any C++ library, and then I can take some other compiler and compile some other piece of C++ that calls my library, and it will Just Work. I can then go back to my library, and make a bunch of ABI safe changes, just as I would have to do in C, and compile my library again, with yet another compiler. At that point the program that was using the older version of my library, would continue to work with the new build of my library without needing to be recompiled. This is because C++ is ABI stable. If I am in C++, and I make an ABI breaking change to something that is used as a base class elsewhere, then I have broken the ABI. But this problem also exists in C, for exactly the same reason, for example lets make some silly example C If I am a C library, and my header declares a struct struct AwesomeThing { intptr_t foo; }; void doSomething(struct AwesomeThing* thing) { thing->foo = 0; } And then someone uses my library in their code: struct ImAwesomeToo { struct AwesomeThing theAwesomest; int* thisFieldIsGreat; }; int doSomethingElse() { struct ImAwesomeToo thing; thing.thisFieldIsGreat = malloc(sizeof(int)); doSomething(&thing.theAwesomest); free(thing.thisFieldIsGreat); } Obviously this is a somewhat silly example, but now say I make a change to my library: struct AwesomeThing { intptr_t foo; double bar; } void doSomething(struct AwesomeThing* thing) { thing->bar = 42; } By the standard rules I haven't "broken" ABI, but now that call to free() is going to cause problems. That's the fragile base class problem. If you are making an API that will have ABI stability requirements you have to expend quite a bit of effort designing the API so it's not only pleasant to use, but also can be evolved without breaking the ABI. As with C APIs, the people who make C++ APIs, know how to make them robust as well. That said you could have a C or C++ ABI that is ABI stable, it just hurts performance, and obviously adopting that would break ABI :D Anyway, the problem with what rust and co are saying, is that the same source can result in different ABIs from one compiler version to the next, or for one API to compile to a different ABI depending on what the rest of the code in the project is doing. That means the OS can't use the safe language as an actual OS API, which I just think is wasting an opportunity. Swift manages, and ostensibly performs the same kind of optimizations within a module, which is most of what you want. That said because it's the system API all objects are refcounted, and the recount is atomic - I was writing a raytracer in it (this is how I learn programming languages) and the refcount overhead was annoying to deal with. Obviously there are trade offs in all the choices, but I still feel like rust, etc could do more. Rust has rich support for annotations, so an "abi_stable" annotation seems like it would be perfectly reasonable - it would be in keeping with rust's general theme of the default behaviour not having any implicit performance costs, but would be easy and very clear when you were making something into an API.
  - saagarjha 4y ago
    > The final problem with the safe languages - with the exception of swift - is that they are all hell bent on not providing even just basic ABI stability. It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface. Carbon isn’t looking to do this either. The “solution” they’ve come up with is that you just recompile everything and get things on the same ABI, which is not surprising considering how Google operates internally.
  - pjmlp 4y ago
    .NET has always supported interop with C++, first with Managed C++, then C++/CLI, and nowadays via Windows Runtime (C++/CX and C++/WinRT). Likewise JNI has always had support for COM like models, and the C API is written in such way that the struct layouts can be used as C++ classes instead, with implicit this on method calls.
saagarjha 4y ago
> it's more modern and flexible governance structure You mean where Google has majority control over what does and does not go into the repo?
humanrebar 4y ago
To be fair, the compatibility is a design goal, not a complete feature as such. Even C++ struggles to be compatible with C++. I expect Carbon to have at least as hard a time with it, especially given the "bazaar" that is the C++ build and packaging ecosystem. I also expect that Carbon will have a hard time tracking C++ as it evolves. It could freeze C++ feature development? Or it could target an old and aging C++ standard? Point is, I'm not taking C++ compatibility as a given. It seems very hard and may require a lot of big tradeoffs.
- TillE 4y ago
  The compatibility target is C++17, which I imagine was chosen primarily to avoid the complexity of modules in C++20. They're also excluding non-trivial preprocessor macros, and saying that you'll probably have to write a bit of glue code in some unusual situations. It's a very realistic take on C++ interop, but still well beyond anything offered by other languages.
  - formerly_proven 4y ago
    If the goal of Carbon is considered to be an off-ramp for Google's C++ projects, then Carbon does not have to evolve with C++. Google can just say "we use up to C++17 and Carbon" for these projects.
    - humanrebar 4y ago
      Yeah, but there will probably be a window in which that offramp is generally interesting. If the worldwide C++ codebase moves along, carbon becomes less accessible as a viable choice. Ironically, Google (googletest, gRPC, etc.) has been more agressive than most in dropping support for older C++ standards.
      - pjmlp 4y ago
        Since Apple and Google have focused on their own languages, clang steam went out, as no one else seems that interested in improving ISO C++ support, rather the LLVM foundations, which require C++17 as basis. If the likes of Intel, AMD, ARM, IBM, Embarcadero,.... don't step up in ISO C++ support at upstream, clang will stay mostly C++17 with some bits and pieces from C++20. It is already ironic, that after so many years of being joked for their non-standard extensions, VC++ has the best ISO C++20 support.

by bbkane 4y ago

deleted 4y ago

[deleted]

usrnm 4y ago

Some of the biggest problems with C++ come from its backwards compatibility with C. Yes, it wins you users in the short term, but it's a pain to support as both languages evolve

olliej 4y ago
The binary compatibility is the big deal. The other safe languages have explicitly taken the view the interop with C++ is bad, and so we should instead do interop with the significantly less safe C instead. The real killer is that the lack of any interaction with C++ means that you can’t do any real incremental adoption of one of those safe languages in any big security critical projects. Saying that the solution to C++ is to just not use it ignores the reality that C++ exists, and large projects in C++ exist. It doesn’t matter if you don’t like C++. The final problem with the safe languages - with the exception of swift - is that they are all hell bent on not providing even just basic ABI stability. It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface. So I can have two libraries both written in rust, and the entire safety of it is contingent on each library talking to the other through a C API.
- staticassertion 4y ago
  > The other safe languages have explicitly taken the view the interop with C++ is bad I think it's more that interop with C++ is hard and ultimately a lot less valuable than interop with C, which is what the vast majority of languages use for FFI. > It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface. I don't see how that leads to "it doesn't matter"
  - __float 4y ago
    If you consider the context of Carbon (Google having a _lot_ of C++), solving for "interop with C++ is hard" might be considered worth the price. Whether that's true in practice...? I guess we'll need a few more years to tell.
    - staticassertion 4y ago
      Of course, that's why they're building it. They're solving a very specific, niche, hard problem. It would make no sense for other languages, which want to solve more general problems, to tackle C++ interop over C.
      - olliej 4y ago
        I do think this is very much a google project specifically because they have a lot of C++ and recognize that there needs to be a path to a memory safe environment, and that is why this project exists. But I don't think the goal is inherently wrong, nor do I think it's niche - there is a lot of C++ in the world, and much of it would benefit from being memory safe. A lot of the largest projects and certainly many of the most heavily used software projects are written in C++. I think you'd agree that having them no longer be be trapped in a memory unsafety tarpit would be a Good Thing. Let's imagine someone came out with a magic C++ compiler that had 100% source and ABI compatibility and had no performance costs, but was completely memory safe - remember "magic". You'd obviously expect, if not demand, that every C++ project switch to that magic compiler. So let's imagine we're on a scale from 1 to 10, where 1 is the memory safety of current compilers and 10 is our magic clearly impossible one. Obviously every step we can go towards 10 is great, but is going to come with trade offs in adoption cost. So on another 1 to 10 scale where 1 is rewriting in some other random language (rust, etc) and 10 is your current compiler, then you want the new language to be as close to 10 as possible. One thing you could do is build all your code with ASAN or a similar mechanism, that would have low adoption cost, a dramatic improvement in runtime safety, but a huge performance cost (time for another 1 to 10 scale?). Carbon appears to be an attempt to design a language with a reasonably high score in all of the scales - no 10s, but mostly 7s or something. I personally think that there are things we could do to C++ that would make a meaningful improvement to safety without having the solution be "rewrite in other language", but I won't fault a project saying "we'll support incremental adoption" as their adoption path in exchange for stronger safety.
- usrnm 4y ago
  > The other safe languages have explicitly taken the view the interop with C++ is bad It's not that it's inherently bad, it's just insanely difficult to do and, probably, isn't worth the pain. Carbon's approach to solving this problem includes embedding a custom C++ compiler as part of its toolchain, and at this point it's just the idea, who knows if they will be able to actually do it. > they are all hell bent on not providing even just basic ABI stability Right, the famous stable C++ ABI
  - mkoubaa 4y ago
    Interop with c++ is definitely inherently bad.
    - olliej 4y ago
      I get that this is kind of facetious, but don't you want things like your browser engine to be in a memory safe language?
  - olliej 4y ago
    ...yes? The C++ is absolutely ABI stable, and is described in excruciating detail, as demonstrated by all those C++ libraries, that you don't have to recompile for on every OS update. I suspect you're confusing when you make an ABI change, without changing the API, which is indeed an easy thing to do: You have to make sure that you only add members to the end of objects, however that exact constraint also applies to C.
    - KerrAvon 4y ago
      Fragile base class problem is solved, then? When did that happen?
      - olliej 4y ago
        No, but that's also not relevant as C++ is ABI stable. I can take any C++ compiler, and I can compile any C++ library, and then I can take some other compiler and compile some other piece of C++ that calls my library, and it will Just Work. I can then go back to my library, and make a bunch of ABI safe changes, just as I would have to do in C, and compile my library again, with yet another compiler. At that point the program that was using the older version of my library, would continue to work with the new build of my library without needing to be recompiled. This is because C++ is ABI stable. If I am in C++, and I make an ABI breaking change to something that is used as a base class elsewhere, then I have broken the ABI. But this problem also exists in C, for exactly the same reason, for example lets make some silly example C If I am a C library, and my header declares a struct struct AwesomeThing { intptr_t foo; }; void doSomething(struct AwesomeThing* thing) { thing->foo = 0; } And then someone uses my library in their code: struct ImAwesomeToo { struct AwesomeThing theAwesomest; int* thisFieldIsGreat; }; int doSomethingElse() { struct ImAwesomeToo thing; thing.thisFieldIsGreat = malloc(sizeof(int)); doSomething(&thing.theAwesomest); free(thing.thisFieldIsGreat); } Obviously this is a somewhat silly example, but now say I make a change to my library: struct AwesomeThing { intptr_t foo; double bar; } void doSomething(struct AwesomeThing* thing) { thing->bar = 42; } By the standard rules I haven't "broken" ABI, but now that call to free() is going to cause problems. That's the fragile base class problem. If you are making an API that will have ABI stability requirements you have to expend quite a bit of effort designing the API so it's not only pleasant to use, but also can be evolved without breaking the ABI. As with C APIs, the people who make C++ APIs, know how to make them robust as well. That said you could have a C or C++ ABI that is ABI stable, it just hurts performance, and obviously adopting that would break ABI :D Anyway, the problem with what rust and co are saying, is that the same source can result in different ABIs from one compiler version to the next, or for one API to compile to a different ABI depending on what the rest of the code in the project is doing. That means the OS can't use the safe language as an actual OS API, which I just think is wasting an opportunity. Swift manages, and ostensibly performs the same kind of optimizations within a module, which is most of what you want. That said because it's the system API all objects are refcounted, and the recount is atomic - I was writing a raytracer in it (this is how I learn programming languages) and the refcount overhead was annoying to deal with. Obviously there are trade offs in all the choices, but I still feel like rust, etc could do more. Rust has rich support for annotations, so an "abi_stable" annotation seems like it would be perfectly reasonable - it would be in keeping with rust's general theme of the default behaviour not having any implicit performance costs, but would be easy and very clear when you were making something into an API.
- saagarjha 4y ago
  > The final problem with the safe languages - with the exception of swift - is that they are all hell bent on not providing even just basic ABI stability. It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would allow) interface. Carbon isn’t looking to do this either. The “solution” they’ve come up with is that you just recompile everything and get things on the same ABI, which is not surprising considering how Google operates internally.
- pjmlp 4y ago
  .NET has always supported interop with C++, first with Managed C++, then C++/CLI, and nowadays via Windows Runtime (C++/CX and C++/WinRT). Likewise JNI has always had support for COM like models, and the C API is written in such way that the struct layouts can be used as C++ classes instead, with implicit this on method calls.

saagarjha 4y ago

> it's more modern and flexible governance structure You mean where Google has majority control over what does and does not go into the repo?

humanrebar 4y ago

To be fair, the compatibility is a design goal, not a complete feature as such. Even C++ struggles to be compatible with C++. I expect Carbon to have at least as hard a time with it, especially given the "bazaar" that is the C++ build and packaging ecosystem. I also expect that Carbon will have a hard time tracking C++ as it evolves. It could freeze C++ feature development? Or it could target an old and aging C++ standard? Point is, I'm not taking C++ compatibility as a given. It seems very hard and may require a lot of big tradeoffs.

TillE 4y ago
The compatibility target is C++17, which I imagine was chosen primarily to avoid the complexity of modules in C++20. They're also excluding non-trivial preprocessor macros, and saying that you'll probably have to write a bit of glue code in some unusual situations. It's a very realistic take on C++ interop, but still well beyond anything offered by other languages.
- formerly_proven 4y ago
  If the goal of Carbon is considered to be an off-ramp for Google's C++ projects, then Carbon does not have to evolve with C++. Google can just say "we use up to C++17 and Carbon" for these projects.
  - humanrebar 4y ago
    Yeah, but there will probably be a window in which that offramp is generally interesting. If the worldwide C++ codebase moves along, carbon becomes less accessible as a viable choice. Ironically, Google (googletest, gRPC, etc.) has been more agressive than most in dropping support for older C++ standards.
    - pjmlp 4y ago
      Since Apple and Google have focused on their own languages, clang steam went out, as no one else seems that interested in improving ISO C++ support, rather the LLVM foundations, which require C++17 as basis. If the likes of Intel, AMD, ARM, IBM, Embarcadero,.... don't step up in ISO C++ support at upstream, clang will stay mostly C++17 with some bits and pieces from C++20. It is already ironic, that after so many years of being joked for their non-standard extensions, VC++ has the best ISO C++20 support.