I wonder if this means Carbon is DOA.
I was excited to see what it would be. But I don't think I can argue that it makes as much sense anymore.
I was excited to see what it would be. But I don't think I can argue that it makes as much sense anymore.
The only somewhat realistic proposal in this space is Herb Sutter's cpp2, which is arguably a massive improvement and I'm puzzled why nobody in the standard thought to give it a spin, there's just to much cruft they'll never be able to get rid of unless they make an alternate yet backward compatible syntax with C++ that changes the defaults from "random 80s nonsense" to something better
Not saying you're wrong, just curious if there are numbers backing this up.
The best models can still make sense of it[2], though the tasks so far have been pretty basic. But I do think it gives some evidence that languages which aren’t well represented in an LLM’s training can still be reasoned about and written well by LLMs.
I don't think Carbon is dead, it just all depends on how easy it actually is to rewrite "all of C++" in Rust. (The jury is still out on this one, but it's not looking good.)
It has been the social media that has given Carbon a roadmap that the team never communicated.
As for Cpp2, it was yet another C++ wannabe replacement, sold as if it wasn't, because the chair of ISO C++ at the time, naturally could not be seen as yet another one coming up with C++ wannabe replacements as well.
> 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.
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.
Does it deliver?
Can all existing C++ code be ported to Carbon without refactoring?
It's DOA because Google doesn't have any idea of what Carbon should be, and to be completely honest, at least 80% of what they currently use C++ for should be rewritten Go, you know, that language developed specifically because of the issues with C++ by teams within Google.