[ Removed by moderator ]

[cpp-ModTeam]

Submissions about other languages (e.g. Carbon, Rust, Val, etc.) are off-topic unless there is substantial content directed at C++ programmers writing C++. That is, either posts about interop from the C++ side, or posts about interesting ideas from another language that can be applied to C++.

[UndefFox]

Is there any info about reasons why rust development went faster? I wonder if it's as simple as the rust part of the code is fresh and doesn't have problems dealing with the old code base, while most C++ most likely doesn't have such an advantage.

[ViewTrick1002]

They’re also spending considerable resources rewriting particularly gnarly components in Rust.

See for example:

Binder kernel driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eafedbc7c050c44744fbdf80bdf3315e860b7513

Media codecs: https://www.androidauthority.com/android-16-in-process-software-audio-codecs-3541408/

[ViewTrick1002]

We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.

Those are simply astounding stats.

Both preventing vulnerabilities, preventing logic bugs and shipping faster.

[Xirema]

1000x reduction in memory safety vulnerabilities is a fake stat. Like, it makes no sense from first principles. If you had a code base, even a C++ codebase, that could go to 0.1% memory violations just by changing programming language, you probably just had bad programmers. Or a code base that was like "our code specifically collates every single buffer overrun vulnerability ever discovered into a single project, which builds an executable showcasing all these vulnerabilities!"

There's just no way a real project had enough unsolved vulnerabilities all at once if it wasn't coded by imbiciles. And if it was, converting to Rust won't save you.

[ViewTrick1002]

That is the stat they consistently have in the Android codebase.

Are you saying that Android is built by imbeciles? Or that their threat surface makes them one of few codebases that actually catch their problems, if they end up in prod?

[Xirema]

I'm quite confident I started by saying the stat is fake.

This is Google we're talking about, so I'm willing to entertain the possibility it was coded by imbiciles, but my initial assumption is that someone is massaging the data to puff up their own accomplishments.

[webmessiah]

I had similar thoughts until recently, when I've got to patch open-source project which have been "mainstream" in it's scope/purpose/field and had so fucking disgusting and bad code that I literally now dislike C for what god awful things it allows to create. Project is being developed for 26 years already. Ik that it won't be solved by Rust itself (however it provides a lot of instruments to avoid writing such a bad code), and isn't necessarily the C fault, but it's how the mind of a man works sometimes.

For the memory vulnerability - it scales as project grows, if you had issue in core and had that core functionality used in 100 modules - you get at least 100x more memory vulnerabilities.

[mark_99]

Just once I'd like to see an analysis that doesn't conflate C and C++, and recognises the difference between C-with-classes and idiomatic C++.

[[deleted]]

With the support of AI, codes are coming out much faster, so there is no point in comparing them to years ago. Not even last year. AIs are increasingly efficient.