> In addition, we are exploring more seamless interoperability with C++ through Carbon, as a means to accelerate even more of our transition to MSLs.
Carbon doesn’t really care about memory safety except as a vague “in the future we’ll evolve the language somehow to add more memory safety” statement. The primary goal seems to be to parse code as quickly as possible. So I’m not sure I understand how it improves the MSL story. Or is it saying that interfacing Carbon with a MSL like Rust is easier so carbon is a better bridge to MSL than things like autocxx?
Carbon is still a small team, so it is going to take time to achieve all of our goals. Carbon will need to demonstrate both C++ interop and memory safety to be considered a successful experiment, worth pushing to a 1.0 version. Once those are achieved, we do expect it will be easier to get C++ code to memory safety through Carbon, since that is the purpose it is being created for. The impedance mismatch between C++ and Carbon will be much lower than with Rust.
Parsing code quickly is merely one of those goals we can demonstrate today.
Does memory safety have a flushed out idea? Is it a form of borrow checking or something else? And if I recall correctly thread safety isn’t a target at all right? Not sure how to square that with memory safety as a goal given the two are linked.
It's weird that he excludes data races from the memory safety even though data races can be in the other classes he calls out. Not sure I buy that it's not as relevant for security since use-after-free is a common side effect of data races.
I am also a little confused by it, but we'll see how it goes. Since everything is still subject to change, it's possible that this won't be the final word on the matter, so I'm not too concerned at this stage.
I would have thought carbon would have memory safety from the get go, but having a language where memory safety is one of the primary goals is meaningful in and of itself (as opposed to C++, where memory safety is one of many competing priorities).
> In addition, we are exploring more seamless interoperability with C++ through Carbon, as a means to accelerate even more of our transition to MSLs.
Carbon doesn’t really care about memory safety except as a vague “in the future we’ll evolve the language somehow to add more memory safety” statement. The primary goal seems to be to parse code as quickly as possible. So I’m not sure I understand how it improves the MSL story. Or is it saying that interfacing Carbon with a MSL like Rust is easier so carbon is a better bridge to MSL than things like autocxx?