Carbon Language Successor Strategy: From C++ Interop to Memory Safety - Chandler Carruth - CppNow 23

(Carbon lang dev here.) Carbon is intended to be memory safe! (Not sure whether you intended to write a double negative there.) There are a few reasons that might not be clear: * Carbon has relatively few people working on it. We currently are prioritizing work on the compiler at the moment, and don't yet have the bandwidth to also work on the safety design. * As part of our migration-from-C++ story, where we expect code to transition C++ -> unsafe Carbon -> safe Carbon, we plan on supporting unsafe Carbon code with reasonable ergonomics. * Carbon's original focus was on evolvability, and didn't focus on safety specifically. Since then it has become clear that memory safety is a requirement for Carbon's success, and will be our first test of those evolvability goals. Talks like ▶ this video better reflect more recent plans around this topic.

in “The two factions of C++” · View on HN

>Carbon wants to ship a finished working Carbon language, then bolt on safety (somehow) but, only for some things, not data races for example, so, you still don't actually have Rust's Memory Safety I'm not sure this is correct. As I understand it, Carbon's plan is to add a borrow checker like Rust's. From a recent talk[0][1] by one of the lead developers: >Best candidate for C++ is likely similar to Rust’s borrow checker [0] slides: [link] [1] relevant timestamps: ▶ this video ▶ this video

in “Circle C++ with memory safety” · View on HN

You're right. In fact it was in the previous slide[0] from that same talk. Thanks for pointing that out. [0] ▶ this video

in “Circle C++ with memory safety” · View on HN

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] [link] [1] relevant timestamps: ▶ this video ▶ this video

in “Secure by Design: Google's Perspective on Memory Safety” · View on HN

After the talk, the activity on it is nearly zero since then, in a world where ideas are cheap, show me the code, this does not seem promising to me. On the other hand, carbon has been very actively developed since its announcement, which also claims to be a typescript-for-c++. Now it also wants to be a memory safe: ▶ this video I'm forced to learn rust but I hope carbon will take off ASAP so I can be more productive and my (carbon) code can interface with c/c++ code easier than rust.

in “Toward a TypeScript for C++"” · View on HN

I haven't carefully read the relevant part of the spec, but I imagine that pointers have to be modeled as not subject to tearing, otherwise safety guarantees would completely fall apart. The flip side of this is that adding "fat pointers" safely to Java would be very difficult. Fat pointers are widely used in languages such as Go, Rust, and Swift to represent both slices (pointer + length) and various forms of dynamic dispatch (pointer + vtable). In Rust, this is safe because data races are forbidden, enforced by the type system. I consider Go and Rust to be "safe-ish" in that data races can happen, and can violate safety. Apparently this hasn't led to huge problems in Go. Thus, the roadmap for Carbon[1] targets a comparable level of safety, not trying to prevent data races, but aiming for memory safety in single threaded contexts. [1]: ▶ this video

in “C++ Memory Model: Migrating from x86 to ARM” · View on HN