Hacker News Reader

Comment by uvdn7 | Hacker News Reader

> Large Scale Codebase Migrations and Optimizations: Argon agents are working on migrating C/C++ codebases to Rust across Google—scaling from tens of thousands of lines in core libraries like re2, libgav1 up to 800K+ lines for the Fuchsia OS Zircon kernel.

To me this is way more significant than other random c++-to-rust-AI-rewrite. If they can pull it off on core C++ libraries en masse, I don't know if C++ will still be relevant in a few years.

I look forward to a post from google on this effort.

View on HN

> I don't know if C++ will still be relevant in a few years.

And people are worried about human extinction when this is the potential trade-off!

C++'s death cannot come soon-enough.

Seriously though, things have changed so incredibly rapidly in the past year or so. I have never been such an efficient or such a proficient engineer than I have this past year (delivering feature after feature, project after project, faster and better than I could before with better feedback from users etc) and I don't even see the code any more. It could be c++, it could be python, or java or what ever - I don't really care any more: the computer deals with that trivia while I concentrate on what to build and how it should work.

Its amazing. It really is.

If Fuschia ever gets finished, that's a pretty good benchmark we've reached AGI.

Fuchsia shipped to many millions of devices today as an OTA in 2021. What do you mean finished?

that's microfuchsia.

I don't think it's worth trading off a risk of human extinction against the ability to convert C++ code to Rust more efficiently.

No, probably not. But that's not an accurate depiction of the stakes.

So when will LLVM be rewritten in Rust?

There is a blog post on (the early baby steps of) that: https://bughunters.google.com/blog/scaling-memory-safety. We have multiple AI-assisted Rust rewrites running in production now.

(Full disclosure: I am one of the coauthors)

A concern with these LLM-driven rewrites is that the Rust code isn't really idiomatic, it ends up being C++ code in a trench coat (raw pointers everywhere, manual validation of thousands of unsafe blocks). So far every publicized rewrite I'm aware of has had an "oh and we'll definitely spend the thousands of hours needed to fundamentally rework the code to properly utilize lifetimes later" admission tacked on at the end. Has there been progress in improving that aspect during the LLM phase of the rewrite? If so that would be an incredible win for the industry!

> Has there been progress in improving that aspect during the LLM phase of the rewrite?

I'd say so! We aim to have our replacements to be `forbid(unsafe)` - no raw pointers - outside of `ffi.rs`. Of course it's tricky because we need to interoperate with existing C code, but we've been trying to come up with abstractions that make this a bit more ergonomic (https://github.com/google/safer_cffi).

"I don't know if C++ will still be relevant in a few years."

The standards body members are still fighting about whether memory safety is important enough to change the language for, so, I would guess the answer is "no".

Yeah that was abundantly clear when Bjarne Stroustrup published "A call to action: Think seriously about “safety”; then do something sensible about it"[0] as a reaction to NSA's recommendation to no longer use C/C++.

[0] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...

C++ will outlive you.

Well, sure, but that doesn't mean it's not in a decline that is very unlikely to reverse course. Fewer people this year are starting new projects in C++ than last year, and fewer people than that will be starting new projects in C++ next year. And, as the models get really good at porting and the cost (both in terms of tokens and human supervision) comes down, there will be an avalanche of ports from less safe languages to safer languages.

This year, maybe next, maybe a year or two after that, is probably the most C++ lines of code in production use there will ever be. Why would one choose C++ for new projects at this point? There are niches where Rust is still uncomfortable or just doesn't have the support, but not for much longer. Models are very good at Rust and good at porting to Rust. And, Rust is a good language for models because it is so strict...it helps keep them in line.

> Fewer people this year are starting new projects in C++ than last year, and fewer people than that will be starting new projects in C++ next year.

Let's put [Citation needed] on this and let's assume that your personal opinion bubble of developers doesn't really represent the combined worlds software industry. Mind actually proving that there's a significant decline of use of C++ outside the hype crowd?

> Why would one choose C++ for new projects at this point?

Why indeed would you choose a language supported on every running platform on this world with a massive library of supported dependencies and mature compilers developed by stable teams.

(I'd probably also personally choose Rust for new projects, but let's make this a practice in "not everyone is like me" empathy.)

Guess which compiler backends many of those languages are using, because the authors don't want to invest into bootstraping?

Where did I say all C++ code will immediately disappear?

"Well, sure, but that doesn't mean it's not in a decline that is very unlikely to reverse course."

Which taken to the logical conclusion will mean its disappearance.

Except there are plenty of industry standards that only acknowledge C and C++, and safer languages that depend on them for their own compilers, including mighty Rust.

COBOL has been in decline for almost the entirety of my time on this earth. And, yet....

There are billions of lines of C++ code in production use. That doesn't disappear overnight, and I've never said it would or even suggested it would disappear overnight. But, the relevance of C++ for the average developer seems likely to never be higher than is it today, and the amount of code written in C++ vs. safer languages, seems likely to decline.

You're arguing with a different assertion than the one I've made.

It may decline, yet until those safer languages get fully bootstraped, someone will keep writing fresh C++ to keep those compilers and language runtimes going.

COBOL latest ISO version is from 2023, by the way.

Of course. So will Cobol.

Depends, who is going to rewrite LLVM in Rust, while expecting the same level of contributions LLVM enjoys nowadays?

If no one is reading or writing Rust code at that point, it all being agent driven, Rust itself is going to be a very short step before it gets disinter-mediated away and it's English -> complex heterogenous machine code across GPU/TPU/CPU/xPUs. Not sure Rust fans or C++ haters have thought this through.

This. The next gen is LLM direct to machine code. Watch MSFT in this space with their dev tool industry -this will be the master stroke

Hmm, is it though? Compilers relieve agents of the burden of much symbolic work, like many other tools that give agents value over a pure LLM.

This is such a bad take given the current LLM agents

High level languages :

  - compress low level patterns into high level abstractions which save context/token
  - express higher level meaning through things like names
  - express and enforce constraints through type system

LLMs are context constrained, do really well with tools that help them iterate towards a correct solution (type systems) and work on human language (although they are compressing it to be more token efficient).

Why would you take something compilers are really good at (translating high level concepts into low level hardware instructions) and bake that into LLMs

If anything LLM programming language will be something like high level IR that's token optimized, but honestly the AI labs are so lazy (or bad) at fundamental engineering (look at their sandboxing solutions LOL), they are going to keep pumping training on shell/python/rust RL environments.

At some point, models will be so smart, hardware will be so cheap that it makes sense for the LLM agent to just write code as low level as possible to optimize for performance and efficiency.

These things are hard for a human to do, but easy for a machine to do.

We are not there yet, not in 2026. Maybe in 2030?

I predict mid-2028 for this

Rate of change is increasing too fast.

Models are likely already doing this inside AI labs because it can be hundreds of millions of dollars for every percentage point increase in hardware inference efficiency.

A smarter agent can write a better compiler and leave the intent in densely packed/verifiable language structure that can encode propositions low level code cannot.

That is my point as well, 5 GLs are coming.

The notion of human-readable/human-safe programming languages will be irrelevant in a few years, not just C++. They may use Rust, Zig, Lean, or maybe some other LLM-generated hyper-optimized intermediate language with a strong type system and compiler, but chances are, we will read less and less of it, until we basically never read code at all.

I know this is somewhat of a meme now but I do think the predominant language will be "typing/speaking to a coding agent in your native language."

LLM should soon be language indifferent/independent, the upcoming years Devs will touch less and less code and more of a LLM as the top interface and debugging tools as the next layer. I just can't see anyone writing an ounce of code in 1-2 years.

I'm still amazed that they still have coding interviews that tests you on syntax. when agentic/ai assisted engineering practices is way more important. What they should test you on is the top layer like architecture, concurrency concepts, UI optimization concept of a particular language API, how to debug, how to test, more of a how to read code instead of writing. They need to test you on speed at which you would detect bad code, over engineered code, bad architected code and how to remedy it.

Yeah, if they can make it work at google scale then no one would absolutely question it anymore

Reply on news.ycombinator.com