> Argon agents are working on migrating C/C++ codebases to Rust across Google
Man, I remember back in the days when the cppnext team was refusing to even consider Rust, instead looking at absurd stuff like Carbon and Swift (!), even though half of the engineering staff already knew where this was headed. I hope they got a few good promos out of the delays at least.
> 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.
I think that's overstating it. Carbon promises a reliable transition; getting an LLM to rewrite in Rust depends on the LLM being smart enough to never make a mistake that it can't catch with (existing or its own freshly created) tests.
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.
What you know with Carbon is that the subset of code that you can port mechanically is behaviourally equivalent to the original. This is massive, and something you can't get from LLM translation.
The bar isn't getting it perfect. The bar is merely parity with the legacy C++ code that wasn't perfect either, which nobody wants to maintain either.
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.
tazjin · · focus · HN ↗
Man, I remember back in the days when the cppnext team was refusing to even consider Rust, instead looking at absurd stuff like Carbon and Swift (!), even though half of the engineering staff already knew where this was headed. I hope they got a few good promos out of the delays at least.
timmg · · focus · HN ↗
I was excited to see what it would be. But I don't think I can argue that it makes as much sense anymore.
pornel · · focus · HN ↗
> 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.
akoboldfrying · · focus · HN ↗
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.
fg137 · · focus · HN ↗
Does it deliver?
Can all existing C++ code be ported to Carbon without refactoring?
akoboldfrying · · focus · HN ↗
fg137 · · focus · HN ↗
akoboldfrying · · focus · HN ↗
pornel · · focus · HN ↗
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.
akoboldfrying · · focus · HN ↗
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.