HN Reader

The 160k → 90k LOC reduction is nice, but the parallel rollout is the more interesting part. Running Rust alongside the C++ version and using differential fuzzing to check equivalence is a lot more realistic than “rewrite and pray.” You get incremental validation with the old system as a fallback. Curious how long they ran both before cutting over.

Binary size is a real concern on the client side. On servers the Rust stdlib overhead usually doesn’t matter, but when you’re shipping to billions of mobile devices, every KB counts. Good to see they invested in build tooling instead of just accepting the bloat.

> We believe that this is the largest rollout globally of any library written in Rust.

I think that crown currently goes to https://github.com/googlefonts/fontations which is included in Chromium, not sure if it's on all platforms yet. Moreover, the translative dependencies of Fontations (click through https://crates.io/crates/fontations/0.3.0/dependencies) should have an even (slightly) larger install-base.

EDIT: from the quote you can also gather that they don't use https://github.com/signalapp/libsignal

> over 3 billion people to message securely each and every day.

Whatsapp is a chat application with 3 billion daily active users.

For those of you in the US (where Whatsapp is seldom used), this is a fact worth remembering.

If you want to build products for the rest of the world, you need to know how those users think and breathe - and for 3 billion of them, Whatsapp is how they talk.

> We believe that this is the largest rollout globally of any library written in Rust.

I suppose this is true because there's more phones using WhatsApp than there are say Windows 11 PCs.

Given that WhatsApp uses libsignal, is it safe to assume that they haven't been using the Rust library directly?

The hardest part of a rewrite like this is usually maintaining bug-for-bug compatibility with the legacy parser rather than the actual Rust implementation. Most real-world media files are malformed in some way that the C++ code implicitly handled, so if you write a strict parser you end up breaking valid user data. Differential fuzzing seems like the only practical way to map that behavior without manually reviewing millions of edge cases.

> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...].

They don't say what they did about it, do they? Did they just accept it?

> "WhatsApp provides default end-to-end encryption for over 3 billion people".

Wasn't there news lately that they can still read your messages somehow?

Very cool! I'm wondering if Signal is doing something similar? libsignal is implemented in Rust, but I don't know about the other parts.

I love how Meta will do anything but prevent phishing and prepaid credit card scams in Whatsapp/Messenger

Quite impressive, I did not know so many bugs were due to memory access.

Cool - now we only need to get selling-you-out-for-profit-Zuckerberg out of WhatsApp to make it really trustworthy.

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 differential fuzzing approach is clever — way safer than a big-bang rewrite. Running both versions in parallel to catch edge cases before switching over is how you actually ship rewrites without breaking production. The 160k to 90k LOC drop is impressive, but the real engineering win is the validation strategy.

On binary size, static linking with LTO should handle most of the bloat without needing custom stdlib builds.

Let's see how this unwrap()s in production scnr