Concept products are not real products. Their purpose is often to make a point, to prove something is possible, to make a brand look cooler, or just to have fun. I don't think I would ever see this car flying on the road myself. But part of me likes the fact that there are people out there making crazy things like this. It is more fun.
> 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.
> 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.
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++.
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.
"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.
> 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.)
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 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.
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.
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.
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.
> But solving problems is only a tool and proxy for achieving the primary goal of conceptual understanding and insight. Forgetting this in the world of AI may turn the tool against the primary goal.
I will quote Richard Feynman - “the prize is in the pleasure of finding the thing out, the kick in the discovery”.
I am not saying that should be the case for everyone in every discipline. But if there is one subject that is mostly pure curiosity driven (instead of worldly impact), it is math. Robbing them the primary motivation is brutal.
If all problems are solved by a machine, what do we have left to satisfy our curiosity, our desire to explore, and where can we find the pleasure of “figuring the thing out”.
reply