> Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.
So the reason for Carbon to exist is gone. C++ code can be migrated straight to Rust without Carbon's stopgap.
LLMs are very good now, but they are still stochastic (when temp > 0), and Google has a lot of code -- i.e., many rolls of the die.
Does it deliver?
Can all existing C++ code be ported to Carbon without refactoring?
LLMs are fuzzy when generating, but such conversions aren't done one-shot. Review and test feedback loops are there to catch the random errors. The frontier models are getting good enough at this.
When LLM is instructed to generate idiomatic safe Rust (rather than literal 1:1 unsafe translation), it benefits from a lot of feedback from the compiler.
Whatever QA there was to ensure C++ was good enough can be applied to the Rust version too.
Right, I'm also talking about making the new Carbon code behaviourally equivalent to the old C++ code, i.e., bug-for-bug compatible (except w.r.t. C++ bugs caused by UB).
> Whatever QA there was to ensure C++ was good enough can be applied to the Rust version too.
The point is that all that QA over the years was a vast amount of effort by highly-paid Google engineers, which could be (mostly) avoided by mechanising the conversion as far as possible, which is something that Carbon's approach can do and LLM translations can't.
I'm not against LLM translations per se. Ultimately it's an engineering decision like any other. I'm just pointing out that, similar to the benefits of using a strongly typed language over relying purely on tests, using an approach that guarantees to eliminate a large class of possible problems has many advantages, especially at scale.