4 ms·

> We believe that substantial improvements can be achieved through an incremental transition to a partially-memory-safe C++ language subset, augmented with hard

by majido 3y ago

> We believe that substantial improvements can be achieved through an incremental transition to a partially-memory-safe C++ language subset, augmented with hardware security features when available. Google’s own Carbon language is positioning itself as C++ successor with an incremental path towards a memory-safe subset. It is odd that the article didn’t even mention it.

luke-stanley 3y ago
People might then discard the whole whitepaper as pushing Carbon, there are probably lots of other options that would be worthy of mention. Is Carbon an actual subset, because the syntax looks different to me in the Wikipedia page example? I'd love to see a list of candidates and how they compare.
- steveklabnik 3y ago
  Carbon is not a subset of C++, it will have a memory safe subset of itself, like Rust does. That said, Carbon’s definition of memory safety does not include data race safety, and so will not have a borrow checker.
  - Vt71fcAqt7 3y ago
    Unless something has chnaged since this talk[0][1], I don't think that is accurate. >Best candidate for C++ is likely similar to Rust’s borrow checker It is stated clearly in the talk that this is true for Carbon as well [0] https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/index.html#/105 https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/in... [1] relevant timestamps: https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s
    - steveklabnik 3y ago
      Hmm, this was exactly the talk where I got this information from! I thought that he specifically said that since the idioms were too different, it wouldn't be possible. I will have to re-watch it, thank you.
steveklabnik 3y ago
The Carbon folks are very clear that it is nowhere near ready, an experiment, and that it may not even work out. They suggest using Rust if you can. I think given that context, it makes sense that it’s not here, and when it becomes more real in a few years, it might get reevaluated then.
- pjmlp 3y ago
  I really don't get where people get the "Carbon is production ready" vibe from.
  - steveklabnik 3y ago
    I don't think they do, specifically, they just know it exists. I am probably one of the most likely people in the world to be tracking what Carbon is up to, yet I only really started paying attention last week. It's hard to keep up with many things.
    - pjmlp 3y ago
      Usually the remarks tend to be as if they already had a compiler ready and were building stuff with it. Meanwhile, the last public talks were about building the frontend.
mike_hearn 3y ago
The paper does mention it, if you read to the end. The blog post doesn't because according to the paper, Carbon's memory safety story isn't worked out.
fl0ki 3y ago
> an incremental path towards a memory-safe subset I was always extremely skeptical of this claim. Let me take the best case here: in a few years, a language called Carbon exists which interfaces seamlessly with C++ code while also having a subset no less safe than Rust. All of that seems possible. That's putting aside the question of how safe they actually do plan to be, which could only threaten the value proposition further. I'm really giving them the best case here out of good faith. What does that get us in practice? We may not have "bindings" as such, but we still need some hand-crafted safe adapter between unsafe types and safe types. The Carbon pitch deck presupposes that this is much better than safe wrappers for machine-generated bindings are today, without a single example of how it will be better. The investment in easier C++ bindings for Rust will face similar challenges. Reusing existing C++ types can be made easier, but it's not clear how they can be made safer without hand-crafted safe wrappers. Once you have those safe wrappers, at least the rest of your code is in Rust, which famously already delivers on its ambitious promises. In summary, while I am willing to believe a language can both be easier to interoperate with C++ and have a safe subset, I am skeptical that this means you can avoid having to create safe wrapper APIs for the unsafe C++/Carbon types. If you have to do that anyway, what remains of Carbon's value proposition in practice? All I see is "you won't have a file of C++ bindings", which is a questionable benefit when tools make that file anyway, and there's a ton of investment -- including from Google itself -- into those tools.

by majido 3y ago

luke-stanley 3y ago

People might then discard the whole whitepaper as pushing Carbon, there are probably lots of other options that would be worthy of mention. Is Carbon an actual subset, because the syntax looks different to me in the Wikipedia page example? I'd love to see a list of candidates and how they compare.

steveklabnik 3y ago
Carbon is not a subset of C++, it will have a memory safe subset of itself, like Rust does. That said, Carbon’s definition of memory safety does not include data race safety, and so will not have a borrow checker.
- Vt71fcAqt7 3y ago
  Unless something has chnaged since this talk[0][1], I don't think that is accurate. >Best candidate for C++ is likely similar to Rust’s borrow checker It is stated clearly in the talk that this is true for Carbon as well [0] https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/index.html#/105 https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/in... [1] relevant timestamps: https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s
  - steveklabnik 3y ago
    Hmm, this was exactly the talk where I got this information from! I thought that he specifically said that since the idioms were too different, it wouldn't be possible. I will have to re-watch it, thank you.

steveklabnik 3y ago

The Carbon folks are very clear that it is nowhere near ready, an experiment, and that it may not even work out. They suggest using Rust if you can. I think given that context, it makes sense that it’s not here, and when it becomes more real in a few years, it might get reevaluated then.

pjmlp 3y ago
I really don't get where people get the "Carbon is production ready" vibe from.
- steveklabnik 3y ago
  I don't think they do, specifically, they just know it exists. I am probably one of the most likely people in the world to be tracking what Carbon is up to, yet I only really started paying attention last week. It's hard to keep up with many things.
  - pjmlp 3y ago
    Usually the remarks tend to be as if they already had a compiler ready and were building stuff with it. Meanwhile, the last public talks were about building the frontend.

mike_hearn 3y ago

The paper does mention it, if you read to the end. The blog post doesn't because according to the paper, Carbon's memory safety story isn't worked out.

fl0ki 3y ago

> an incremental path towards a memory-safe subset I was always extremely skeptical of this claim. Let me take the best case here: in a few years, a language called Carbon exists which interfaces seamlessly with C++ code while also having a subset no less safe than Rust. All of that seems possible. That's putting aside the question of how safe they actually do plan to be, which could only threaten the value proposition further. I'm really giving them the best case here out of good faith. What does that get us in practice? We may not have "bindings" as such, but we still need some hand-crafted safe adapter between unsafe types and safe types. The Carbon pitch deck presupposes that this is much better than safe wrappers for machine-generated bindings are today, without a single example of how it will be better. The investment in easier C++ bindings for Rust will face similar challenges. Reusing existing C++ types can be made easier, but it's not clear how they can be made safer without hand-crafted safe wrappers. Once you have those safe wrappers, at least the rest of your code is in Rust, which famously already delivers on its ambitious promises. In summary, while I am willing to believe a language can both be easier to interoperate with C++ and have a safe subset, I am skeptical that this means you can avoid having to create safe wrapper APIs for the unsafe C++/Carbon types. If you have to do that anyway, what remains of Carbon's value proposition in practice? All I see is "you won't have a file of C++ bindings", which is a questionable benefit when tools make that file anyway, and there's a ton of investment -- including from Google itself -- into those tools.