> 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.
Longtime Google engineers have it particularly bad. Some of it could be bad-faith promotion hunting I suppose, but the core problem is that their "find something to work on" culture leads to some insanely dysfunctional ideas around ownership. In the reverse, too; only at Google can you be the head engineer for a service necessary for $10B in ARR and never really realize it.
Also the internal tooling culture there is just insane. I'll never forget the day the last SUPER_ESSENTIAL_TOOL was marked as "Deprecated - do not use!" while the only replacement was still marked "Pre-release -- use at your own risk!". I can't pretend to know what dynamics led to that cause it was so far from my org, but I can't imagine they were healthy ones!
Carbon was clearly DOA the moment it was announced, IMHO. It looked cool but it served none but Google, and now with LLMs you have a massive incentive not to use a niche or new language due to how better LLMs get the bigger the corpus is
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
Cpp2 has been dead for a while afaik, while Carbon is still going.
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.)
Yes, but at least it was a real thing with a serious proposal behind. Even if Carbon ships, what value would it give in 2029 or whenever it is in a world where writing rust or heck even C++ is now way easier and foolproof (as long as you know where to guide an LLM)
The Carbon team has always been the first one to assert this is for Google internal purpose first and formost, everyone else should go to Rust, Java, Go, C#, Swift,... whatever fits their workloads.
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.
Is there evidence that LLMs generate better code in more popular languages? I get the sense the "experience" translates between languages and it can reason in any language just fine. I write Clojure code using a rather esoteric framework (Pathom3). There is probably very little similar code out there (it's definitely a tiny fraction of the training dataset) but it seems to do just fine
Not saying you're wrong, just curious if there are numbers backing this up.
In my experience LLMs are way better when they "know" a language "instinctively". It's just that unless your language is very niche, the corpus is usually good enough. I tried using Claude to write my own personal language a while ago (I wrote a toy compiler decades ago) and it struggled a bit, because you could see in it's reasoning it had to "repeat" the syntax equivalence to itself while it read the code. It didn't just "know" it could use a given construct to do something; conversely Astra, when carefully instructed to do so, can plop down esoteric template code that works the first time, because it just "knows" it's the right stuff to write
I built a brand new language to test this[1]. Not only is the language different to basically any other language but it also tries to be adversarial against LLM understanding.
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.
None of these solutions has a chance. That should be clear from the beginning. The last thing the C++ community will do is to migrate to an incompatible language that only looks/reads like C++ -- that did not happen in the past 30 years and will not happen now.
Version 0.0.0.0 after 4 years. Their goal of "full interop with C++ while being a completely new language without any of the flaws of C++" is plain absurd.
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.
> 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.
There is 0 practicality in inventing an entirely new coding language that only one company uses, and you have to teach it to thousands of new engineers. Rust exists and fits the job totally fine and is used in more places and has actual support outside of a single entity (i.e you can actually hire people that feasibly know the language).
It was clearly done because some PL guys at google really wanted to make a new cool language and Google was the perfect place to incubate it without it getting axed. Probably got a couple of promos out of it too. This is clearly not the best use of time or money, but I guess if you're google you have so much of both it probably doesn't really make a dent, and you can keep a few very smart people happy with shiny new projects.
Also, LLMs being used for a large portion of coding nowadays sort of remove the need for these types of languages, IMO. They make less "silly" bugs (both logical and structural) that languages like this are meant to catch, and they are much better at languages that are better represented in the training corpus. This somewhat obviates the need for very niche "type/dummy-safe" languages like carbon (and even rust/zig, imo). So even if you did want to use Carbon, you'd likely have to bootstrap a decent amount of your own "good" carbon code to post train an LLM, and even then, it likely won't have that big of a gain vs just having an LLM write C++ or even Rust. If you are a company that still reviews code, you should just have an LLM code in a language most people can understand anyway to make verifiability tractable.
Hmm, I don't disagree with you that LLM's remove the need for type-safe languages, but as the blog mentioned, Google is porting their C++/C code to rust. Does this mean the port is waste of time and that they should just rely on the LLM's to catch memory errors?
I mean Rust definitely has a better tradeoff than Carbon in this case, re readability/verifiability by a person (and sufficiently good internet training data).
I personally think that you _could_ use an LLM to catch these types of boundary case errors without having to port the _entire_ C++ codebase to Rust, but maybe pre-emptively porting to Rust now can catch some of these cases for cheaper than doing a full LLM sweep. Also more cynically, its a good benchmark lol.
I guess if you really believe in curve of LLM capabilities you should just use a language that has the best performance, safety, flexibility, and extensibility, since in the limit few/no people will actually read the code anyway. I think this ends up being Rust.
I'm not an expert on this. But isn't it the case that C++ code could have errors that span the entire codebase, like a setup in file A triggered by a bug in file B which is immensely far away on the import graph? A classic would be a use-after-free. To me that's the thing that Rust can help with, even if silly bugs aren't being written by AI.
The other thing is just that rewriting some old human-written codebase in Rust probably immediately catches many bugs. It would be hard to prompt the AI to properly scan for such bugs itself, they're lazy when working in that modality.
I am an expert (in formal methods). LLMs absolutely need more safeguards rather than less. Not because they /need/ them in order to produce functioning code, or even because they produce as many braindead bugs as humans, but because in an era of explosive code quantity, what has become valuable is (assured) code quality.
Going back to C++ would be particularly bizarre to me given that AI is also very proficient at verified languages. Not merely typesafe, but languages comprising their own spec languages such as Rocq and Lean.
I predict that in the next decade: (1) the market will understand the difference between a "code writer" and a "spec writer," with (2) the expectation that the latter is overwhelmingly more necessary than the former in an AI-dominated field, and (3) there will emerge more useful and less mathematically specialized formal verification alternatives to Rocq and Lean, and a filling-out of the tooling gap of between "static typing" and "interactive proof assistant," perhaps in the vein of ACSL-like contract annotations, and (4) there will be a subsequent shift in the traditional curriculum for programmers. Since educational change is slow (and spec writing depends on good coding fundamentals anyway), perhaps (4) is a stretch, but I'm more confident in the first three.
For me personally, when doing development with LLM's, you've won me over towards using safer languages rather than looser ones. Because for one thing, the developer working with an LLM still has to remember to ask it to check for things like memory leaks and security issues. And (as I understand it), LLM's are statistically in the way they work and some level of randomness is always apart of their answer, so there is always a chance they will miss something. Interesting
actually, not my conclusion, just paraphrasing what Boshalfoshal was saying. In fact, am also questioning whether this is true, but personally haven't done development enough with LLM's to make my own determination:)
> There is 0 practicality in inventing an entirely new coding language that only one company uses, and you have to teach it to thousands of new engineers
They did that for Go and it seems to have worked out for them though.
Three famous guys on Google's pay check did it on their 20% to avoid C++, and they were lucky Docker and Kubernetes projects pivoted from Python and Java respectively into Go.
I’m not entirely sure Google should have both Go and Carbon but when you have billions in server costs it makes sense to do extreme stuff for even basis points of performance. I’m still surprised at how much java there is.
I don't know what the exact deal is, but I assume Hack meets specific use cases at Facebook and can be put in production. It doesn't matter if anyone else is using it.
By comparison, virtually nobody is using Carbon at Google for production code.
The counterexample, ironically, is Flow. It's practically irrelevant these days -- many (if not most) of Facebook's open source projects use typescript.
Rust is not the end of history. One of the difficulties with the language lies exactly with porting existing code written in an OOP style to idiomatic Rust, as those codebases weren't written with ownership in mind.
Such rewrites will contain judicious uses of Cell, RefCell, unwrap() etc. which make for ugly code that's not exactly simple to understand and might even have some landmines (crashes).
Getting rid of these requires a subtantial amount of engineering effort, which I'm not sure how well these LLM manage.
Given the nigh-universal experience of LLMs producing an ungodly mess when left to their own devices, I have my concerns.
A RewriteInRustBench would be unironically useful at this point since all the main agents can write it reasonably well despite its relative scarcity in the input data.
Rust is the best language for LLMs b/c it gives by far the best debug messages. Just tons of verifiable reward signal for post-training. Even the most rudimentary LLMs can school me on idiomatic Rust
Evidence needed. I think for certain kinds of outcomes it has very strong advantages, but these advantages are not a given as 'best for LLMs' :)
On the other hand, Rust's borrow checker is very picky, and even a frontier LLM still sometimes struggles to respond to roadblocks sensibly (refactoring so whatever it's trying to do can be done safely) rather than stupidly (introducing some horrible global arena thing so it can make the borrow checker go away). A lot depends on how good your instructions are, and how good the existing code is, since bad input begets bad output.
I've (more or less; I've read quite a bit of the code) vibecoded several houndred thousand lines of Rust and I've not seen this happen a single time. It sounds like something it'd do when you ask it to "write a linked list while satisfying the borrow checker". Are you sure you haven't (possibly) unknowingly been giving it instructions which ended up luring it into doing these things?
Yep! In our tests, we found Zig to be a pretty good fit to translate C++ codebases.
And static analysis + agents are good enough at keeping the memory management in check. Compared to Rust, there's no magic so it's easy for devs and agents to reason about.
If you're curious: <a href="https://github.com/okcontract/oksolc" rel="nofollow">https://github.com/okcontract/oksolc
Not always. In my experience, if you're not working on a small, trivial codebase, LLMs will sometimes just create spaghetti unreadable, inefficient code to satisfy the constraints of the type system/borrow checker.
I've narrowed in on only using Go or Rust generated code (Go for APIs right now) and rust for some TUI or other thing. TS for web interfaces (w/React).
After the current onslaught of 0 days on linux and other C projects combined with the new incredible ability to convert codebases to another language I think we will start to see this actually happen.
I'm not saying we blindly vibe convert Linux to Rust, but I think it could be a valid idea to start converting small parts and carefully auditing them.
I've been a Swift/Obj-C engineer for my whole 15 year career. I now have all these odd jobs I have going on Raspberry Pis around my house that LLMs have written in Python. I'm now having them convert some of them to Rust and I am astonished on how fewer resources are used.
I converted some Ruby stuff at a previous job to Rust pre-ai days and it was incredibly how much less memory they took and how fast it ran. But we still built everything else in Ruby because finding Rust devs was hard.
> The end result is a memory-safe video decoder that runs 2.7x faster than the Rust port, with identical video output, bringing it closer to the optimized C++.
So ... Rust still can't beat the C++ implementation :-D
Sorry, didn't mean to ignite a langwar, but it's still interesting to see.
"Safe Rust" being closer to "optimized C++".
And those "optimized C++" usually incldues assembly code, so it's a huge improvement.
Of course, Rust is not a magic, so just porting to Rust wouldn't make this performance improvement.
It seems their AI overfitted code to Rust compiler to find safe Rust code that compiles to efficient assembly.
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.
ChickeNES · · focus · HN ↗
baq · · focus · HN ↗
bbor · · focus · HN ↗
Also the internal tooling culture there is just insane. I'll never forget the day the last SUPER_ESSENTIAL_TOOL was marked as "Deprecated - do not use!" while the only replacement was still marked "Pre-release -- use at your own risk!". I can't pretend to know what dynamics led to that cause it was so far from my org, but I can't imagine they were healthy ones!
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.
qalmakka · · focus · HN ↗
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
Mond_ · · focus · HN ↗
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.)
qalmakka · · focus · HN ↗
pjmlp · · focus · HN ↗
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.
geokon · · focus · HN ↗
Not saying you're wrong, just curious if there are numbers backing this up.
qalmakka · · focus · HN ↗
dom96 · · focus · HN ↗
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.
1 - <a href="https://killswitch-lang.org" rel="nofollow">https://killswitch-lang.org
2 - <a href="https://bench.killswitch-lang.org" rel="nofollow">https://bench.killswitch-lang.org
fg137 · · focus · HN ↗
YuechenLi · · focus · HN ↗
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.
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.
DetroitThrow · · focus · HN ↗
vovavili · · focus · HN ↗
Maxatar · · focus · HN ↗
gorbot · · focus · HN ↗
boshalfoshal · · focus · HN ↗
It was clearly done because some PL guys at google really wanted to make a new cool language and Google was the perfect place to incubate it without it getting axed. Probably got a couple of promos out of it too. This is clearly not the best use of time or money, but I guess if you're google you have so much of both it probably doesn't really make a dent, and you can keep a few very smart people happy with shiny new projects.
Also, LLMs being used for a large portion of coding nowadays sort of remove the need for these types of languages, IMO. They make less "silly" bugs (both logical and structural) that languages like this are meant to catch, and they are much better at languages that are better represented in the training corpus. This somewhat obviates the need for very niche "type/dummy-safe" languages like carbon (and even rust/zig, imo). So even if you did want to use Carbon, you'd likely have to bootstrap a decent amount of your own "good" carbon code to post train an LLM, and even then, it likely won't have that big of a gain vs just having an LLM write C++ or even Rust. If you are a company that still reviews code, you should just have an LLM code in a language most people can understand anyway to make verifiability tractable.
vovavili · · focus · HN ↗
computerdork · · focus · HN ↗
boshalfoshal · · focus · HN ↗
I personally think that you _could_ use an LLM to catch these types of boundary case errors without having to port the _entire_ C++ codebase to Rust, but maybe pre-emptively porting to Rust now can catch some of these cases for cheaper than doing a full LLM sweep. Also more cynically, its a good benchmark lol.
I guess if you really believe in curve of LLM capabilities you should just use a language that has the best performance, safety, flexibility, and extensibility, since in the limit few/no people will actually read the code anyway. I think this ends up being Rust.
chis · · focus · HN ↗
The other thing is just that rewriting some old human-written codebase in Rust probably immediately catches many bugs. It would be hard to prompt the AI to properly scan for such bugs itself, they're lazy when working in that modality.
Paracompact · · focus · HN ↗
Going back to C++ would be particularly bizarre to me given that AI is also very proficient at verified languages. Not merely typesafe, but languages comprising their own spec languages such as Rocq and Lean.
I predict that in the next decade: (1) the market will understand the difference between a "code writer" and a "spec writer," with (2) the expectation that the latter is overwhelmingly more necessary than the former in an AI-dominated field, and (3) there will emerge more useful and less mathematically specialized formal verification alternatives to Rocq and Lean, and a filling-out of the tooling gap of between "static typing" and "interactive proof assistant," perhaps in the vein of ACSL-like contract annotations, and (4) there will be a subsequent shift in the traditional curriculum for programmers. Since educational change is slow (and spec writing depends on good coding fundamentals anyway), perhaps (4) is a stretch, but I'm more confident in the first three.
computerdork · · focus · HN ↗
diegojromero · · focus · HN ↗
tclancy · · focus · HN ↗
That feels like a really strong conclusion. I’m not clear on why any safeguard isn’t a useful safeguard if you let agents write all the code.
computerdork · · focus · HN ↗
mike_hearn · · focus · HN ↗
They did that for Go and it seems to have worked out for them though.
pjmlp · · focus · HN ↗
Google themselves aren't big Go users.
lesuorac · · focus · HN ↗
I’m not entirely sure Google should have both Go and Carbon but when you have billions in server costs it makes sense to do extreme stuff for even basis points of performance. I’m still surprised at how much java there is.
fg137 · · focus · HN ↗
By comparison, virtually nobody is using Carbon at Google for production code.
The counterexample, ironically, is Flow. It's practically irrelevant these days -- many (if not most) of Facebook's open source projects use typescript.
torginus · · focus · HN ↗
Such rewrites will contain judicious uses of Cell, RefCell, unwrap() etc. which make for ugly code that's not exactly simple to understand and might even have some landmines (crashes).
Getting rid of these requires a subtantial amount of engineering effort, which I'm not sure how well these LLM manage.
Given the nigh-universal experience of LLMs producing an ungodly mess when left to their own devices, I have my concerns.
fg137 · · focus · HN ↗
bvinc · · focus · HN ↗
It’s absurd to think that Carbon is the solution to memory safety when rust exists and Carbon’s memory safety story is basically “TBD”.
minimaxir · · focus · HN ↗
culi · · focus · HN ↗
LarsDu88 · · focus · HN ↗
bitexploder · · focus · HN ↗
rafram · · focus · HN ↗
nchie · · focus · HN ↗
zahlman · · focus · HN ↗
Karrot_Kream · · focus · HN ↗
hbbio · · focus · HN ↗
And static analysis + agents are good enough at keeping the memory management in check. Compared to Rust, there's no magic so it's easy for devs and agents to reason about.
If you're curious: <a href="https://github.com/okcontract/oksolc" rel="nofollow">https://github.com/okcontract/oksolc
fireant · · focus · HN ↗
lossolo · · focus · HN ↗
throwitaway222 · · focus · HN ↗
iillexial · · focus · HN ↗
konart · · focus · HN ↗
Many pieces of software are going to be just blackboxes worked by AI. You will be maintaining output quality and stability and that's it.
david-gpu · · focus · HN ↗
Maybe we should let them do their thing and instead focus our attention on the higher-level stuff like specifications and testing.
adamrezich · · focus · HN ↗
6thbit · · focus · HN ↗
DrBenCarson · · focus · HN ↗
<a href="https://www.ll.mit.edu/r-d/projects/translating-all-c-rust-tractor-benchmarks" rel="nofollow">https://www.ll.mit.edu/r-d/projects/translating-all-c-rust-t...
ksec · · focus · HN ↗
pshc · · focus · HN ↗
Gigachad · · focus · HN ↗
I'm not saying we blindly vibe convert Linux to Rust, but I think it could be a valid idea to start converting small parts and carefully auditing them.
hectdev · · focus · HN ↗
Gigachad · · focus · HN ↗
keepitwiel · · focus · HN ↗
hollowturtle · · focus · HN ↗
and start everything all over again? current c/c++ tools have been audited for years
fg137 · · focus · HN ↗
6thbit · · focus · HN ↗
Imagine they aren't even familiar with rust but are deeply familiar with the product.
mlmonkey · · focus · HN ↗
So ... Rust still can't beat the C++ implementation :-D
Sorry, didn't mean to ignite a langwar, but it's still interesting to see.
pasteleft · · focus · HN ↗
Of course, Rust is not a magic, so just porting to Rust wouldn't make this performance improvement. It seems their AI overfitted code to Rust compiler to find safe Rust code that compiles to efficient assembly.
himata4113 · · focus · HN ↗
manbash · · focus · HN ↗
But there are other criteria. The move to rust might've also resolved numerous potential memory-safety bugs in the decoder.
stephbook · · focus · HN ↗