> 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 c

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