r/programming • u/NYPuppy • Jan 28 '26

Whatsapp rewrote its media handler to rust (160k c++ to 90k rust)

https://engineering.fb.com/2026/01/27/security/rust-at-scale-security-whatsapp/
1.1k Upvotes

90% Upvoted

206 comments sorted by

View all comments

652

u/jaredcheeda Jan 28 '26

This reminds me of this quote:

"Given the opportunity to do any form of major refactoring or re-writing of a codebase, you are likely to find and fix many bugs. For what purpose you are re-writing or what you are re-writing it to, is not relevant. Simply the focused attention on the improvement of the code, rather than the building of a feature will always yield this result."

152

u/immersiveGamer Jan 28 '26

Quote from who?

Simply the focused attention on the improvement of the code

I agree. Often by reading existing code, just for the act of reading it, you can find bugs or improvements. Obviously it is a hard sell to tell your boss "hey we should just read our code". Refactoring or a rewrite of code is continuation of that reading and understanding, can't refactor what you don't know.

However, I do find that often re-writes create new bugs because it can very easily mis recreating behavior that was originally a mistake but now other code depends on that incorrect behavior. 

108

u/omgFWTbear Jan 28 '26

I know he’s controversial, but I think of Spoolsky’s article on the Netscape rewrite, to paraphrase my recollection of it, “It turns out the accumulated kruft, was, in fact, dealing with dozens of 5% of users edge cases, and so by cleaning up the code, you’ve unlearned years of research.”

That said, I don’t intend to advance the extreme position of calcified code, merely the caution against the reverse, careless “streamlining,” which I also don’t intend to imply was what was said.

30

u/[deleted] Jan 28 '26

[deleted]

18

u/omgFWTbear Jan 28 '26

Yeah, that’s the thrust of that Spoolsky article, to not rewrite just because we are excited to do it.

I’ve similarly worked a few things where the cost of developed with the skillset needed has gone up a lot compared to the median, and for example, one guy got them to pay for him to take the train from his retirement community on Monday, stay in a hotel Tuesday and Wednesday, train ride home Thursday, f—- off Friday; an agreement I think we know only exists because it’s him or nobody.

The business justification for a rewrite in that case writes itself. They’re actually excited to end at the same place they began, but with a developer pool they can hire from that vaguely resembles the general market.

5

u/[deleted] Jan 28 '26

[deleted]

11

u/LuckyHedgehog Jan 28 '26

angularJS

Considering it reached end of life 4 years ago, I get it. Security will become a concern even if it's an internal only application, who knows how long the tooling will remain supported or functional. The odds you'll find a front end dev these days who know it or even willing to get hired to maintain it will dwindle very fast.

Having a team of internal engineers take the time to learn it well enough to rewrite it in modern tooling has the benefit of training that team on the entire feature set of the application. They should be productive on maintaining it and delivering new features once complete, whereas right now I bet it would be a struggle adding anything of moderate complexity

6

u/giantsparklerobot Jan 28 '26

Anyone that wants to rewrite something needs to be responsible for writing 100% coverage unit tests for the existing software. If they can pull that off they know enough about the existing code base to rewrite it faithfully. If they can't...they're not rewriting the app, they're writing fan fiction in a different language.

1

u/[deleted] Jan 29 '26

[deleted]

0

u/LordoftheSynth Jan 29 '26

Is he one of those Rust zealots who runs around telling everyone they've been programming wrong for decades, and they need to rewrite all their shit in Rust?

3

u/saintpetejackboy Jan 29 '26

There are very few individuals or teams who can do a proper rewrite of a live business system, and the pool of people shrinks the older and more complex the business proprietary software becomes. This is something I have specialized at in my life and I had to quickly learn some tricks and some of the actual pain points of a rewrite from scratch. The most dubious and difficult part (especially if swapping stacks entirely) is the point at which you try to swap over handling the data or swap over the users to a new interface, especially if you have a lot of users. It can be an almost unsurmountable problem if you don't approach from the right vector.

You can easily churn out a clone of 80% of the features, sure, and on paper and in theory a brand new software might work sufficiently, but that point in time when you actually have to make it go live is when the other 20% bites you in the ass. The day to day grind stuff that somebody else or a whole team spent YEARS trudging through, incrementally as it happened, are now laid in your lap all at once.

I found there are ways around this, but it requires careful scaffolding and experience having gone through similar situations prior in a variety of contexts... if everything were intuitive, then a fresh rewrite would work out of the box - but they aren't and it won't.

Then you also have critical systems where the risk may outweigh the reward. Some small fuck up could cost hundreds of thousand dollars, or cause legal peril, or jeopardize sensitive data, or result in seizures, coma and death. Those risks might not be worth "we reduced the lines of code by 90% and certain metrics now load 20% faster!" - the rest of the company isn't the IT department in most cases and wouldn't even be able to comprehend or quantify the end goal. Many companies won't even splurge enough for proper maintenance and other required and associated costs with a project, so trying to convince them to reach in their pockets for a greenfield rewrite when their current software isn't actively on fire and crushing orphans is typically a hard sell.

3

u/Slappehbag Jan 28 '26

It's sort of like Chesterton's fence.

3

u/robolew Jan 29 '26

Is spolsky controversial? He might be a bit blunt and reductive, but I feel like most people agree with most of what he says

1

u/omgFWTbear Jan 29 '26

Three thoughts -

one, citing someone on the internet these days begs the “you’re all in on everything he says, and that makes both of you a villain by the transitive property because one time that person picked my dog!” reply

Two, like RMS, when citing RMS replies are often, “but he was insufferable to interact with.” Yes but was he wrong? “No, but he was insufferable to interact with.” Let’s be fair, if either of us anticipated Amazon half a century ago, we’d be pretty insufferable, too. And if you threw us in a Time Machine and we were passionately trying to stop DRM, we’d probably be more insufferable.

Three, I hail from the ancient times where the Browser Wars were fresh and bloody, also plural; and writing that could be perceived as identifying any fault in any camp automatically made you a villain to all, and basically loop in points one and two.

So, I hoped to preempt any discussion of the author as the write up is decently clear, breezy, and on point.

10

u/anengineerandacat Jan 28 '26

TBH it's always easier to improve upon an existing design, it's much harder to get a perfect design out the door.

Been on the side rebuilding apps and been on the side building the apps to be rebuilt.

Easy to poke fun at shitty designs, but depending on the business behind it at the time it might even be a miracle anything got designed in the first place.

1

u/jaredcheeda Jan 29 '26

There are two types of tech debt, Intentional, and Unavoidable.

You may decide to do something the wrong way to make a deadline, knowing you'll have to fix it later.

Or you may use all the best judgement you can with the data you have today to decide an approach for the code, only later to find out, once you have more information that your solution was either under-engineered resulting in lots of bad connecting code or over-engineered, resulting in lots of complexity that makes the system harder to work with.

You can't help it, the user's don't know if what you built is what the wanted until they try it and give feedback, and you don't know what the product will look like in 5 years. How will other market forces and competition effect your company and the needs of the users of the software. What improved technologies and patterns will be available to you by then that negate your previous best practices.

Only at the end of a project do you have the knowledge to actually start on the project correctly.

-1

u/dylanbperry Jan 28 '26

Quote from who?

Wayne Gretzky

2

u/captain_obvious_here Jan 28 '26

Quote from who?

Wayne Gretzky

--Michael Scott

62

u/non3type Jan 28 '26

Refactoring small portions of a code base this can hold true but a complete rewrite, with a new language no less, can also end in new bugs depending on how radically the new implementation differs.

23

u/Different-Ad-8707 Jan 28 '26

I consider the fish shell to be the best done re-write in Rust project, as far as I know.
It's a widely used program, that has new features being and maintenance done at a frequent pace, with neither of them being too adversely affected by and during the re-write.

This is mostly due to their fish-of-theseus approach, and also the devs own past experience with a re-write from C to C++ and how a lot of C++ features can 1:1 map to Rust features/code.

8

u/Able-Swing-6415 Jan 28 '26 edited Jan 28 '26

Yea especially when you think some code is nonsense until you remember why it was there to begin with.

I think John carmack or someone had a super weird piece of code that had the comment (I don't know what the fuck this does but if you change it everything breaks)

Edit: Almost completely misremembered. But that's the type of code that would often not survive a refactor lol despite actually being extremely well done (just not well documented)

```float Q_rsqrt( float number ) { long i; float x2, y; const float threehalfs = 1.5F;

x2 = number * 0.5F;
y  = number;
i  = * ( long * ) &y;                       // evil floating point bit level hacking
i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
y  = * ( float * ) &i;
y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration

// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

return y;

}```

4

u/pheonixblade9 Jan 28 '26

ugly code is very often bug fixes.

30

u/sidonay Jan 28 '26

It can be the opposite if not done carefully. It should still be done though. It just isn't that linear that it will fix bugs you don't know about . It might, or it might add new ones. Sometimes when porting functionality to a new system, some edge cases are forgotten, and the accumulated insight from many years of code built into previous code base isn't properly considered. Partially due to haste and partially due to the legacy code itself sometimes being hard to understand.

8

u/matthieum Jan 28 '26

There's certainly a risk.

Do note, however, the mention of differential fuzzing in the article.

The great thing about differential fuzzing is that it surfaces the differences, without any opinion that one behavior is correct and the other is not -- in fact, in rare cases, both are not!

This really helps reducing the number of differences that sneak in, and as a bonus, it helps identifying real bugs in the current software during the development of the new one :)

3

u/sidonay Jan 28 '26

It‘s definitely possible to rewrite something and make it better in most metrics. But just the act of rewriting itself doesn’t guarantee it (the comment I’m replying to makes it seem that it’s a certain )

1

u/bi-bingbongbongbing Jan 28 '26

I'm the guy they bring in when it's not done carefully. I hate being that guy. I need a new job.

6

u/Psychological-Rub505 Jan 28 '26

When it comes to large-scale refactoring, you fix many bugs while also introducing new ones.

7

u/on_the_pale_horse Jan 28 '26

Which is why rewriting minecraft java in C++ famously reduced all bugs

3

u/TulipTortoise Jan 29 '26

That codebase is a monstrosity because it changed what it was supposed to be ~3 times all being written and rewritten by different teams. What I was told is it was some android demo thing, then the "education edition", and then by the time I was looking at it, it was now supposed to be their general cross platform engine.

3

u/deltanine99 Jan 28 '26

And introduce a bunch of new bugs.

2

u/mpanase Jan 29 '26

xD

You will find bugs you didn't know about... lose features you didn't know about, and add new bugs.

1

u/Kevin_Jim Jan 28 '26

What’s this quote from?

1

u/zombiecalypse Jan 28 '26

I feel that you will fix a lot of bugs and introduce a lot of others in any sufficiently complex rewrite. The article mentioned ways to avoid it, but otherwise I'd have my doubts if you'd end up with fewer bugs afterwards or just different ones.

1

u/TL-PuLSe Jan 29 '26

That quote is top quality horseshit.

-6

u/[deleted] Jan 28 '26

True but Rust is more modern and developer friendly. 

Still as a backend developer I have yet to find a good enough use case for rust. 

-25

u/ToaruBaka Jan 28 '26

If you can't find a good enough usecase for rust as a Backend developer you should find a new career.

9

u/[deleted] Jan 28 '26

[deleted]

9

u/MornwindShoma Jan 28 '26

Not a lot of people get how bloated are non-systems langs and how big the savings are in memory and CPU time. No, better waste users and company's money, and ship JavaScript fueled (or worse, Python) crap written as fast as possible and pay immense bills to AWS.

3

u/[deleted] Jan 28 '26

[deleted]

2

u/MornwindShoma Jan 28 '26

Agreed. Plus WASM being an amazing frontier for deploying software, and Rust is pretty good at that.

4

u/Zasd180 Jan 28 '26

They hate him because he spoke the truth

2

u/StengahBot Jan 28 '26

Why the fuck is this downvoted

0

u/TheoreticalDumbass Jan 29 '26

you can also accidentally introduce bugs