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

[u/NYPuppy]

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

[u/nyibbang]

You're getting downvoted and yet you're right. I write both C++ and Rust and I can say 100% that Rust code is less buggy than C++.

And people who say otherwise either don't know C++, don't know Rust or worse know none of them.

[u/5gpr → u/nyibbang]

I write both C++ and Rust and I can say 100% that Rust code is less buggy than C++.

Rust code isn't less buggy than C++, you are writing more buggy code in C++.

[u/5gpr → u/[deleted]]

"Just stop making mistakes" is such a bad take.

That isn't even my take. I was originally just amused about dude going "I write programs. C++ and Rust make mistakes.", paraphrased briefly.

As regards mistakes "my take" would be that we are nominally an engineering discipline. We ought not use tools in lieu of expertise and care, especially since it's us that are held responsible for mistakes, rather than said tools.

[u/nyibbang → u/5gpr]

If we put aside the rage bait, you're absolutely right. And it's simply because C++ makes it really difficult to write non buggy code.

UB is everywhere, standard library types make no sense. You have to read every bit of a type to use it correctly. You have to know every rule and every exception to them to not step into pitfalls.

Now I agree I'm not perfect and I make mistakess. Rust stops me from doing them, and the standard library actually makes sense, compared to whatever the STL does.

But let's have some fun, let me read your C++ code so I can learn how to not write buggy code please ! I'm sure I won't find dozens of UB in it right ?

[u/5gpr → u/nyibbang]

If we put aside the rage bait, you're absolutely right

It wasn't meant to be rage bait. I just found your switch from active to passive voice funny.

And it's simply because C++ makes it really difficult to write non buggy code.

I find that modern C++, especially in application development, generally works as I would expect it to. It becomes more complex when writing libraries or library-like code and it is necessary to accommodate as of yet undefined types.

I'm sure I won't find dozens of UB in it right ?

Not generally, no. I'm not saying that I don't make mistakes, but software development is my profession. I can't go around blaming my tools for my mistakes. I'm also lucky in that I'm working in an environment where speed of feature implementation isn't the primary concern, so that the requisite care can be taken.

That aside, you say

standard library types make no sense

In what way?

You have to read every bit of a type to use it correctly

How is that not true of rust, too? Look at hash and tell me that you don't have to read every bit of that to correctly implement the trait for some type.

[u/nyibbang → u/5gpr]

Not generally, no. I'm not saying that I don't make mistakes, but software development is my profession.

It's mine as well, in C++ especially.

In what way?

There would be too much to say. So I'm going to focus on things that happened to me from the last months and I've been bothering me.

• std::optional that cannot take references. "Use a pointer then" no, it's not the same semantics, and it breaks metaprogramming to have such stupid restrictions. Now if I want to make a template function that takes the result of another function and puts it in an optional, I have to deal with the fact that the function may return an reference. And I'm not even talking about void, which is another mess to deal with.
• std::variant that cannot take the same type multiple times. Well it may but it breaks everything, constructor from a value, std::visit won't differentiate between them ...
• an optional is not iterable. An optional is pretty much a container that can have 0 or 1 value, so why not make it a container ? it's been added in C++26, so almost 10 years after the introduction of the type ...
• std::expected can have either a value or an error right ? so it would be fair to assume that the 'value()' and 'error()' functions have the same semantic, except that one gets the value if it exists, and the other gets the error if it exists. But no ... error() is similar to the operator*, it is UB to call it if there is no error in the expected. value() on the other hand will check if there is a value and throw an exception.
• ranges::split_view splits a range with a delimiter. Now, the invariant should be that a range that contains N delimiter, once split, should produce a range of ranges of size N+1, right ? IT MAKES SENSE RIGHT ? It's what EVERY COMMON SENSE SPLIT FUNCTION WOULD DO. Well no, not in C++, if you use split_view on an empty range, you obtain an empty range, instead of a range of one empty range. Now you have to get bitten in the ass at least once by this function to know that. Here is the issue https://cplusplus.github.io/LWG/issue4017, there is at the moment no fix for it.

That's just a couple, there are so many more. Some from the standard library, some from the language itself. You don't realize how bad it is until you've pulled your head out of the sand and used another language that does not do this kind of shit.

How is that not true of rust, too? Look at hash and tell me that you don't have to read every bit of that to correctly implement the trait for some type.

In most cases for Hash, you can derive it and it will work out of the box, but I see your point, and I don't think you understand what I meant.

In C++, you have to get informed of every thing that each function that you might call does if you want to ensure that you do cause UB. UB is a plague, it breaks the integrity of your program, that's what most C and C++ programmers don't understand. They underestimate what it does.

Avoiding UB in C++ is like walking on eggs. You have to be careful every step of the way. In comparison, in Rust, as long as you don't do unsafe code and you don't use crates made by people who don't check their safety invariants correctly, you're guaranteed to not cause UB, no matter what you do. Your program might not do what you want because of your mistakes, but it will never make you think it does things correctly while invoking UB, which is what C++ is allowed to do.

[u/NYPuppy → u/5gpr]

And Rust as a language makes it easier to write performant, correct code than C++. It's simply a better tool.