Carbon is performance-first, so ABI instability is the default. We plan to have opt-in ABI stability, but that story is not well developed yet. Replacing C as the lingua franca is not a goal, at least not yet.
The nightly release of the Carbon compiler can be used via https://carbon.compiler-explorer.com/ . Note that it is definitely a work in progress, it hasn't even reached our v0.1 goals yet, but a good chunk of important functionality is working.
10^12 < 256^5 ≈ 1.1e+12, which isn't too bad. You could also use 10^118 < 256^49, which wastes less but is in bignum land.
But don't you want 10^x to be slightly bigger than 256^y, so you could represent all length-y byte sequences in x-digit number? In this direction, there's 10^53 > 256^22, but that is still in bignum land.
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 https://www.youtube.com/watch?v=1ZTJ9omXOQ0 better reflect more recent plans around this topic.
Not super familiar with Carbon but .. what's the elevator pitch for porting my C++ to unsafe Carbon? Can it be done with an automated refactoring tool or something?
I feel like if I'm gonna go through the whole nightmare of a code port I should get something for it as opposed to just relying on interop
The idea is that it is an incremental process. By default you should be able to make minimal changes to your code and it should mostly just work. Over time you can use features that more tightly couple you to Carbon, such as memory safety. Google's motivation is supporting its massive C++ codebase while providing a path for memory safety and other features. If your use case does not closely mirror that of Google's, namely, that you have 10+ year old code you intend, and have, to maintain, Carbon probably doesn't make sense for you and that is generally made pretty clear for anyone interested in the language.
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.
