This is less about languages and more about so-called AI. One thing’s for sure: it’s becoming harder and harder to deny that agentic coding is revolutionizing software development.
We’re at the point where a solid test suite and a high-quality agent can achieve impressive results in the hands of a competent coder. Yes, it will still screw up, needs careful human review and steering, etc, but there is a tangible productivity improvement. I don’t think it makes sense putting numbers on it, but for many tasks, it looks like there’s a tangible benefit.
I feel similar about the potential of this technique and have heard this from other C++ developers too.
Rust syntax is a PITA and investing a lot of effort in the language doesn’t seem worth the trouble for an experienced C++ developer, but with AI learning, porting and maintenance all become more accessible.
It’s possible to integrate Rust in an existing codebase or write subparts of larger C++ projects in Rust where it makes sense.
I was recently involved in an AI porting effort, but using different languages and the results were fine. Validating and reviewing the code took longer than writing it.
Just like Google’s Rust-in-Android blogs this reads like a PR piece (and in the case of facebook also recruitment piece) with some technical words sprinkled in for effect. The overall communication quality is that of a random startup’s “look what we did” posts.
The interesting aspects, such as how they protect against supply-chain attacks from the dependency-happy rust toolchain or how they integrated the C++ code with the Rust code on so many platforms - a top challenge as they said - remain a mystery.
Would also be interesting to hear how much AI-driven development they used for this project. My hope’s that AI gets really good at Rust so one doesn’t have to directly interact with the unergonomic syntax.
The point of articles like this is to help build credibility for rust adoption. Rust is still not very widely adopted industry wide, and a lot of smaller players only use established technologies that bigger firms have shown works well. Rust is not inevitable, and articles like this are necessary for its future industry adoption.
PR makes it sound like it only benefits the company. It benefits the broader rust community as well. Where was it established that the article must provide you some technical knowledge to learn? I sure didn't go into reading it with the expectation it would.
> The interesting aspects, such as how they protect against supply-chain attacks
There are standard techniques to help manage this that apply across languages, there's no reason to reinvent that wheel.
> My hope’s that AI gets really good at Rust so one doesn’t have to directly interact with the unergonomic syntax.
"Unergonomic syntax" is the battle cry of many people resisting learning a new language. AIs have progressed far enough that they can help you in that learning process, though.
The dependency management and complexity/poor ergonomics are the two major technical problems with Rust. Normally the first one’s ignored while the second is downplayed, so it would have been interesting to see what (if anything) Facebook have done about them.
Not only can AIs help, but they can write most if not all the code and spare the human from learning all the intricacies of individual programming languages.
Problem is, reports are contradictory on compatibility with Rust. We know they work great with simpler/friendlier languages like Go or Python.
> I'm trying really hard to buy European made products and to use European services where possible.
European companies are trying even harder to outsource to China.
In the past months I’ve seen an increase and it feels like almost everything is made in China, from books to Christmas trinkets to clothes and kitchen utensils, it’s a pain the ass to find locally produced goods.
This has a lot to do with the energy crisis triggered by decoupling from Russia, which was never properly put into context and evaluated from an economical perspective.
Massive projects like Qt also push compilers to their limits and use various compiler-specific and platform-specific techniques which might appear as bugs to Fil-C.
For many years, all the projects I’ve been in had mandatory code review, some in the form of PRs (a github fabrication), most as review requests in other tooling.
This applies to everything from platform code, configuration, tooling to production software.
Inside a component, we use review to share knowledge about how something was implemented and reach consensus on the implementation details. Depending on developer skill level, this catches style, design issues or even bugs. For skilled developers, it’s usually comments on code-to-architecture mismatches, understandability, etc. Sometimes not entirely objective things, that nevertheless contribute to developing and maintaining a team consensus and style.
Discussions also happen outside and before review, but we’ve found reviews invaluable.
If a team has yearly turnover or different skill levels (typical for most teams), not reviewing every commit is sloppy. Which has an additional meaning now with AI slop :)
Doing a vehicle check-up is a pretty normal thing to do, although in my case the mandatory (EU law) periodic ones are happening often enough that I generally don’t have to schedule something out of turn.
The few times I did go to a shop and ask for a check-up they didn’t find anything. Just an anecdote.
There was an interesting video on YT where an engineer from a fastener company joined a carpenter to compare their products with traditional joints.
The traditional joints held up very well and even beat the engineered connectors in some cases. Additionally one must be careful with screws and fasteners: if they’re not used according to spec, they may be significantly weaker than expected. The presented screws had to be driven in diagonally from multiple positions to reach the specified strength; driving them straight in, as the average DIYer would, would have resulted in a weak joint.
Glue is typically used in traditional joinery, so less glue would actually have a negative effect.
> Glue is typically used in traditional joinery, so less glue would actually have a negative effect.
And a lot of traditional joinery is about keeping the carcase sufficiently together even after the hide glue completely breaks down so that it can be repaired.
Modern glues allow you to use a lot less complicated joinery.
We’re at the point where a solid test suite and a high-quality agent can achieve impressive results in the hands of a competent coder. Yes, it will still screw up, needs careful human review and steering, etc, but there is a tangible productivity improvement. I don’t think it makes sense putting numbers on it, but for many tasks, it looks like there’s a tangible benefit.
reply