alt.hn

1/28/2026 at 6:21:07 AM

Rust at Scale: An Added Layer of Security for WhatsApp

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

by ubj

1/28/2026 at 2:26:58 PM

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.

by cong-or

1/28/2026 at 2:38:49 PM

Did they say anywhere what they did? Rebuilding the stdlib as part of your build can shrink it a lot depending on how much of it you use, but that is still nightly only. Maybe they went no_std or created their own?

by galangalalgol

1/28/2026 at 3:29:49 PM

They didn't but keep in mind that the app is currently 170MiB. The standard library shouldn't have added more than a few hundred kilobytes. They already likely pay similar costs for c++, but it's more worthwhile as they have a lot more c++ code total.

Also note that if you statically link to the rust std library, lto will excise the majority of it anyways, no need to rebuild it.

by surajrmal

1/28/2026 at 5:17:13 PM

The default hello world stripped with one codegen unit and panic=abort was 342kB both nightly and stable. Adding lto dropped it 42kB in stable and 40kB in nightly. Adding build-std and only building core did not reduce it any further in size.

by galangalalgol

1/28/2026 at 8:59:35 PM

I assume OP is taking about using -Zbuild-std on nightly. This will drop it much more.

by metaltyphoon

1/29/2026 at 3:31:19 AM

That is what I was talking about. It didn't reduce it at all over just lto. If I'd set optimization to z it probably would have gotten some back, but that starts impacting performance

by galangalalgol

1/29/2026 at 7:54:25 PM

This is built with buck, and core/std are built as a source dependency.

by jsgf

1/28/2026 at 4:19:22 PM

> 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

by erithax

1/28/2026 at 6:06:49 PM

Just for reference, Wamedia ships on the major Meta apps and on iOS, Android, Desktop, and Web platforms.

by dcsommer

1/28/2026 at 5:10:18 PM

> 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.

by londons_explore

1/28/2026 at 5:19:03 PM

What one should do about this? I mean, beside working on lowering that number.

(Asking as a European who quite stubbornly refuses to install it - there are dozens of us. Dozens!)

Edit: please don't participate in making WhatsApp even more inescapable as it is today.

by jraph

1/28/2026 at 5:41:18 PM

As a developer, I tried building an app that needs to use Whatsapp for communication. Unfortunately my phone number got blocked by the second test message. No Spam. Not marketing, just a test message to my own number. Along with it, they blocked my entire business, my LLC, and anything tied to it.

I have been trying to get hold of anyone or anything at Whatsapp. I've spent 6 months trying to navigate the bureaucracy. Facebook support claims they can't touch WhatsApp; WhatsApp support ignores the Facebook side. If you're building on WA, have a backup plan.

If any Whatsapp employee reading this can look into my WBA Account 1117362643780814

by harikb

1/29/2026 at 11:27:06 AM

The number is only checked at login, and after that you can now create a WebAuthn passkey (iCloud Keychain/Google Passwords synced to your next phone) for future sign-ins so it's actually only needed for first sign up. So just get a prepaid SIM or eSIM and make another account unless your business is so large that tons of people know your number.

by morpheuskafka

1/29/2026 at 6:49:28 PM

Sorry I am confused. I have a "WhatsApp Business Account", tied to an "Business" (verifications all done). What I am talking about is registering a phone number that acts as the "Sender/Responder" of the messages from my customers. I am not trying to use WhatsApp from my phone manually, but have my app communicate with my customers programatically. Hope this is clear.

I can't do any of the above,

1. Requesting a new test number. Test numbers are placeholder 555 number that works only within WhatsApp test network. Can't get one.

2. Registering a new, real phone number (SIM obtained from a regular tele provider)

3. Disconnecting the WhatsApp product from the Facebook App to reset the integration.

Although the FB app is being used, I don't have any WhatsAppp users (because I have not even made the product), so wiping out any WBA accounts and starting fresh is also okay, if someone can do this.

by harikb

1/28/2026 at 6:01:11 PM

Telegram API is easier to handle as far as I know if that can somehow help (in case you want live ChatGPT or notifications for yourself in a mobile chat)

by rvnx

1/28/2026 at 7:46:18 PM

Telegram's bot API is a lot easier to get started with for sure. It's got some rough edges once you start trying to do anything more complex, though, and the underlying MTProto API is nothing short of bizarre.

I'd urge caution before using them as a component of your business, though. Their business strategy is pretty chaotic and has relied heavily on weird cryptocurrency-adjacent plays (e.g. TON / Fragment / gifts). They've made a couple of attempts to introduce business features, but I'm not sure they've had any substantial uptake.

by duskwuff

1/29/2026 at 11:32:02 AM

Yeah, which is ironic given that it is not E2EE (unless specifically opted in for a private chat, and even then some would argue the MTProto crypto isn't good enough, although those people wouldn't trust WhatsApp ether). WhatsApp is overwhelming associated with legitimate (though in many countries, primarily overseas) users, and Telegram is somewhat associated with shady activities.

That said, Telegram is likely a lot more open for a business type that is legal but still regulated or illegal in some countries (legalized/unregulated substances, tobacco/e-cigarettes, adult content, etc.), probably less worried of random bans/demonetization.

Despite not being E2EE, Telegram also seems to have higher usage in censored countries (Russia and Iran etc). Once a Russian guy in Korea randomly asked if I had Telegram wanting me to take a picture for him since his phone was dead -- obviously had no idea that sounded like a massive scam flag to most Western users.

by morpheuskafka

1/28/2026 at 6:14:20 PM

I will look into it. But my user base is either WhatsApp or plain SMS text messaging.

by harikb

1/28/2026 at 6:58:35 PM

Yeah telegram is so easy to develop with - I was blown away. I was able to spin up a bot that checks for GE appointments with minimal effort.

by yandie

1/28/2026 at 5:24:53 PM

I guess if you want to lower that number, you'd need to build something better, in some way. Answered as another European who've had Whatsapp forever, as some stubborn people refuse to move away from it, and also bunch of businesses use it.

by embedding-shape

1/28/2026 at 5:54:29 PM

Network effect is killer. "better" would include having more than 3 billion people already on it.

Maybe the EU or China will crack down on it. A single company shouldn't decide who gets to talk to half the world. If that company is American they will not tolerate it for long.

Personally DeltaChat is my new favorite Thing but it falls afoul of Zooko's Triangle - A WhatsApp number or POTS number is short because it's centrally controlled and you have to pay for each one. DeltaChat has public keys, so I have 20 of them, and nobody can control who gets one, but they're incredibly long... the QR codes are nightmares.

by 01HNNWZ0MV43FF

1/28/2026 at 6:00:21 PM

> Network effect is killer. "better" would include having more than 3 billion people already on it.

At one point people moved from something else to Whatsapp, and that happened before Whatsapp had 3 billion people on it. If it's good, early adopters will adopt it and want others to adopt it too, then it snowballs from there.

It has happened before, and as long as new regulation doesn't solidify Whatsapp/FB in their position, it can happen again :)

by embedding-shape

1/28/2026 at 7:01:56 PM

WhatsApp happened at a time when, in Europe, you paid for SMS.

WhatsApp allowed people to send SMS without paying, or rather, paying just once to buy the app, so it was instantly valuable if you just convinced your spouse or parents or a single friend to install it.

To overcome it now, you need a lot more effort (or rely on enshittification, which I'm sure will happen).

by riffraff

1/28/2026 at 7:29:35 PM

No, before Whatsapp, people were mostly using Facebook messages, at least where I lived at the time.

And no one was paying per SMS at the time we were using SMS for communication, almost everyone I know were on monthly plans that gave you N text messages and N minutes of calls for static sum each month.

The first people I saw who started using whatsapp, was people who were communicating across the border, because even if you had a monthly plan, those didn't include international messages. Eventually we all converged on whatsapp because that's what outside family and relatives used anyways.

by embedding-shape

1/28/2026 at 7:43:51 PM

WhatsApp launched in January of 2009 compared with Facebook Chat which launched in 2008. WhatsApp saw drastically wider adoption among the general populace and paying for “N text messages per month” is precisely what people refer to as paying per message - WhatsApp had unlimited messaging.

by vlovich123

1/28/2026 at 8:05:36 PM

Is "Facebook Chat" not the same as "Facebook Messenger", the separate chat client? Because I seem to remember a lot of people using the chat built-in into Facebook (not Messenger) a lot earlier than the standalone app/client, maybe I misrecall.

> paying for “N text messages per month” is precisely what people refer to as paying per message

Maybe I said it wrong, "N text messages per month" for me means "Pay us 10 EUR per month, send up to 5000 messages" for example. Doesn't matter how many you send, you pay the same.

While "pay per message" is "Every text message you send, costs 0.01 EUR". Maybe I'm using the wrong words, but that's how I understand it.

Most of the people who were "texters" (in my circles) were on plans offering the first way of paying, while hardly anyone was doing it the second.

Another important part, was that most telecom's had free SMS and calls if you were with the same company (and still do, AFAIK), so constant bickering about what plan people are on and why they don't change so it's free and yadda yadda.

Many people were already mostly texting for free at this point.

by embedding-shape

1/29/2026 at 7:26:45 AM

Facebook chat preceded Messenger which was a rebranding and separating into a standalone app precisely because WhatsApp ate their lunch so bad.

The rates people were paying back then were extortionate - like 60-90% profit margin. When WhatsApp launched, plans were 5-15 euros/month for 100-500 messages with ~0.15 per message for overages. So you might not count the bundle as a per text message, but it really is which you can tell by what happens if you send more than your bundle allowed. Compare that with WhatsApp’s $1/year for unlimited messaging and you start to see the pricing disparity.

Many people were not mostly texting free in 2009. I think you’ve got the timelines mixed up. That started changing towards the mid to late 2010s precisely because of internet-based chat apps on the phone and plummeting data costs making the telco’s SMS pricing plans insane.

by vlovich123

1/29/2026 at 10:59:42 AM

Let me preface this with that my experience comes from Sweden in the 90s and 00s, and is a correct and truthful lived experience of my life. Seemingly, things were different were you lived, and that's fine, but that's not how it worked all across Europe, so at least we can agree on that :)

The initial claim of "WhatsApp happened at a time when, in Europe, you paid for SMS." maybe was true in parts of Europe, but clearly not everywhere. People were mostly using the Facebook chat (not Facebook Messenger/Chat) already before Whatsapp started being used, although Whatsapp in Sweden still isn't as popular as in other countries. In Spain, everyone uses Whatsapp, in Sweden, seemingly the people I talk to only have Whatsapp to communicate with me and others outside the country.

> Many people were not mostly texting free in 2009

Most people I knew definitively were mostly texting for free even before 2009, again, at least in Sweden.

by embedding-shape

1/30/2026 at 6:30:44 AM

I think we can agree that Sweden is not a representative sample of what happened in Europe as a way to explain why WhatsApp became dominant for the majority of people in Europe.

I grew up in Canada so my knowledge is purely from talking with people in non-Swedish parts of Europe that I met and also reading contemporary articles analyzing the space as well as retrospective analysis of what led to WhatsApp’s popularity and dominance.

by vlovich123

1/28/2026 at 8:13:32 PM

The EU has already forced WhatsApp to be interoperable. Of course, Meta complied maliciously, making it a setting that you have to enable, but at least it's a start.

by stavros

1/28/2026 at 8:33:53 PM

I guess the bean counters figured it'd be cheaper compared to ultimately paying the fine they get for maliciously following the rules. Hope the fine ends up large enough to make them wrong :)

by embedding-shape

1/28/2026 at 5:27:09 PM

Make your customer support on whatsapp. "Drop us a message to change your order". Allow ordering/enquiries over whatsapp.

Send 2 factor verification pins over whatsapp - it is more reliable than SMS and generally there is a better 1:1 mapping between whatsapp accounts and real humans than phone numbers, so it is a good anti-spam or good way to distribute "first month free" type deals whilst keeping abuse low.

Obviously make sure all URL's have info cards properly rendered in Whatsapp for good share-ability.

by londons_explore

1/28/2026 at 5:36:03 PM

And now your customers are required to agree to Meta's term of services and to run some black box software, and you are screwed if Meta decides your business or your customers need to be kicked out.

by jraph

1/28/2026 at 5:48:17 PM

[dead]

by sieabahlpark

1/28/2026 at 7:39:17 PM

Force interoperability one way or another. WhatsApp is a closed system, if I want to use an alternative I'm stuck with adversarial interoperability, so stuff like Beeper (which is great, but...) which might get my account banned. Or waiting for some legislation to force WhatsApp to open it's API and let me interact with my contacts there without being locked into their apps

by mfashby

1/28/2026 at 8:33:22 PM

There is legislation in the EU, and BirdyChat announced compatibility.

https://www.birdy.chat/blog/first-to-interoperate-with-whats...

by darrenf

1/28/2026 at 9:45:25 PM

BirdyChat, the existence of which we all first became aware at the same time as that legislation and which nobody can use yet, only join a waitlist... :-)

by jraph

1/31/2026 at 9:00:59 PM

And apparently requires explicit WhatsApp user opt-in to be available. Meta is of course going to maliciously comply as best they can, so they've made sure interoperability is off by default and requires a specific opt in.

by aaravchen

1/29/2026 at 4:37:08 AM

> What one should do about this? I mean, beside working on lowering that number.

Every business in Brazil has an whatsapp to talk to their clients. Sometimes this whatsapp goes into the phone or computer of a real human being. Other times, it's manned by a bot (usually a dumb choose-your-own-adventure bot - I don't see business using LLMs for this here)

Indeed I use food delivery apps (ifood here) only to check out the menu of delivery restaurants, then I search for them in Google so I can order directly from them through whatsapp. This won't work for some dark kitchens, but other than that it's pretty reliable and avoid the middleman

by nextaccountic

1/28/2026 at 7:34:53 PM

Advocate protocols over platforms. Have your government take an active interest in opening up closed communication systems and mandating third-party client access.

by tremon

1/29/2026 at 11:25:10 AM

Well, you now have the right to use third-party apps to exchange messages with WhatsApp users, but apparently your law only covers it if the other user is in the EEA. So you are back to square one when communicating with India, Pakistan, and much of SE Asia, Africa, and MENA.

by morpheuskafka

1/28/2026 at 5:27:04 PM

Can you describe your reasons? I haven't developed an opinion as no one here uses it.

by galangalalgol

1/28/2026 at 5:32:31 PM

I refuse to use proprietary software as much as I can, especially when it has a strong network effect where it encourages others to join.

Meta is also a despicable company, they don't need my help to succeed.

(edit: and I haven't abandoned the idea to switch back to a Linux mobile OS at some point, and WhatsApp would be a pain)

by jraph

1/28/2026 at 7:59:51 PM

Where I come from (Malawi, Africa), WhatsApp is so widespread that most people prefer it over email - to the extent that people don't really check their e-mails unless it's required for work or they are applying for something. For most people, WhatsApp is the de-facto communication channel.

I help moderate a community of developers and we hit the whatsapp group limit of 1024 members and sometimes have to wait for someone to leave (intentionally or accidentally) before we can add new members. We've tried to move people onto "better" platforms like Discord or Slack but we always end up coming back to WhatsApp which is subsidized via MNOs (mobile network operators) social media data/internet bundles and for the fact that most people are just stuck on whatsapp.

by zikani_03

1/29/2026 at 7:50:17 AM

Yeah and we know it is over 3 billion because security researchers from the university of Vienna could read that in one go from one source ip address without encountering any rate limiting:

"phone number, public keys, timestamps, and, if set to public, about text and profile picture. From these data points, the researchers were able to extract additional information, which allowed them to infer a user's operating system, account age, as well as the number of linked companion devices."

See: https://www.univie.ac.at/en/news/press-room/press-releases/d...

by atoav

1/28/2026 at 8:57:35 PM

In markets where Whatsapp is entrenched, it’s already begun to enshittify.

They have ads and spam already (sorry, no-consent messages from businesses). This isn’t even new. [0]

There’s a clear pattern, say “we’ve rolled out strict policies”[1] and then… nothing changes on the ground, and TechCrunch writes another “they’ve fixed it” article a year later.[2]

Also their Communities feature has pretty crap UX.

Yes WhatsApp’s pervasive. But if pervasive was the end of the story, we’d all be using ICQ and AOL. The last thing any country needs is to hand over more of their lives to Facebook [sic].

[0] https://techcrunch.com/2022/10/10/in-india-businesses-are-in...

[1] https://techcrunch.com/2024/11/20/whatsapp-will-finally-let-...

[2] https://techcrunch.com/2025/10/17/whatsapp-will-curb-the-num...

by signal11

1/28/2026 at 6:16:21 PM

Sure, but like with most things, maybe like 200 million max of them in NA/EU would actually bring in real money.

by moomoo11

1/28/2026 at 10:26:36 PM

Honestly? That claim seems a bit(read A LOT) exaggerated. I haven't had whatsapp in a decade and none of my friends(scattered all over Europe) or family uses it. Viber used to be a big deal and to an extent still is in some areas of Europe. Personally I think I've talked almost everyone into migrating to Signal.

by axegon_

1/29/2026 at 5:43:28 AM

No one I know in the UK seriously uses signal. If I'm asking for a phone number from a neighbour it's going to be WhatsApp

by conradludgate

1/29/2026 at 6:10:19 AM

In the Netherlands Signal is getting traction. I talk to most people via Signal, about 85% of my messages are via Signal. Which includes my parents, and I didn't even put them on Signal.

by jsiepkes

1/29/2026 at 6:11:46 AM

Yep.

Nontechnical uncle messaging me on Signal was a great signal that Signal was gaining some social traction.

by DANmode

1/29/2026 at 6:12:17 AM

What part of the UK?

by DANmode

1/28/2026 at 6:34:21 PM

Doesn't this description describe Facebook itself? Should we make apps more like that as well? Because they could not be more polar opposite each other.

by Capricorn2481

1/28/2026 at 10:40:45 AM

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.

by storystarling

1/28/2026 at 10:58:27 AM

It sounds like it's a design goal of this "wamedia" to _not_ maintain bug compatibility with media players.

by dwattttt

1/28/2026 at 12:36:49 PM

I suspect it is actually about maintaining permissiveness for malformed inputs rather than keeping security bugs. I ran into this building ingestion for a print-on-demand service where users upload technically broken PDFs that legacy viewers handle fine. If the new parser is stricter than the old one you end up rejecting files that used to work, which is a non-starter for the product.

by storystarling

1/28/2026 at 5:15:33 PM

AI reply?

by rubymamis

1/28/2026 at 5:57:36 PM

Not AI. Anyway, the real issue is permissiveness vs strict parsing—real-world files are messy.

by storystarling

1/28/2026 at 9:34:42 AM

> 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?

by nevi-me

1/28/2026 at 10:35:20 AM

WhatsApp doesn't use libsignal, and Android is already pretty Rusty and deployed more than WhatsApp around the world (not just smartphone. Tons of "embedded" use cases also run on custom Android)

by marisen

1/28/2026 at 5:27:49 PM

>deployed more than WhatsApp

If you count old Android versions before Rust was added.

by charcircuit

1/28/2026 at 7:48:47 PM

WhatsApp was using libsignal (the C version) when I worked on the KaiOS integration in 2017/2018.

by fabrice_d

1/28/2026 at 10:46:30 AM

Like our gym devices that have a full tablet to run a basic application to control weights, talk about wasting money.

by pjmlp

1/28/2026 at 11:24:13 AM

It doesn't make sense for that device alone, but the vendor probably supplies all the different equipment in the gym. Using a tablet simplifies their supply chain, deployment, debugging/repair, app update process and simply supports more features. There are probably some connectivity features on the device, for example. When you look at all of that together, it's hard to argue it's wasting money.

It's like complaining about Electron apps. For sure I love small native apps like everyone else. But, if Electron enables a company to ship cross-platform apps and iterate faster, who am I to say no?

(I happen to have seen some of those tablets in diagnostic mode and poked around a bit. These things are much more complicated than you think.)

by g947o

1/28/2026 at 1:26:13 PM

Once you price in the cost of integration, plastics, ROHS, CE and other regulatory/certifications, the extra cost of an Android tablet which already has a lot of that starts to make sense.

If you also add in the extra ease of things like device management across fleets etc, it becomes a no-brainer for the manufacturer.

by rswail

1/28/2026 at 4:29:23 PM

The major problem with sticking an Android tablet on to exercise equipment is the difference in life spans. Android tablets are generally going to last you 4-5 years. Weight equipment should be able to last decades. There is some simple & cheap hardware that can last decades, but it is legitimately harder to program.

Even worse was an article some months back about Android tablets hooked to heating & cooling systems expected to last 20 years. There's no way those things are making it at scale.

by jerf

1/28/2026 at 4:36:14 PM

> Weight equipment should be able to last decades.

"should" or "actually can"? Do you have references to show that's the actual lifespan of the equipment, mechanically?

by g947o

1/28/2026 at 8:48:20 PM

Weight training equipment lasts decades all the time. It's just big piles of metal, it's not hard to get right.

What actually prompted the engineering-CYA "should" is if the Android tablet is controlling some sort of robotic system for selecting weight sizes, that that system might have an expected life span on par with a tablet, being a physical thing moving around some pins or something in a potentially hostile user environment. That'll break long before anything else would.

by jerf

1/28/2026 at 10:31:09 PM

So you don't have a reference.

I'm just going to ignore this.

by g947o

1/29/2026 at 2:49:54 PM

If you are the sort of person who needs a reference for "weight equipment lasts a long time", feel free. Whatever guilt and shame you think I should be feeling over such a claim, believe me, I don't. I'm more in the "feeling pity for you" department here; I've been around enough to know what kind of person types messages like this.

by jerf

1/28/2026 at 12:14:33 PM

Well, doesn't look like to me, and a plain ESP32 with a touch screen would do the job for displaying a weight bar with plus, minus and reset count buttons.

by pjmlp

1/28/2026 at 12:35:54 PM

And then you get to a cardio unit where you want a completely different set of features and have to start over. Going lean on hardware only makes sense when you push out a very high number of units, when you have to deal with battery constraints or when you just have a lot of intertia, the combination of existing codebase and developer filter skillset.

by usrusr

1/28/2026 at 12:48:11 PM

Except all the machines have the same feature set I mentioned.

Agree that wanting to hire cheap developers is why they did it that way, the current interface is so laggy that I would bet it is Web based, on top of running Android for nothing.

by pjmlp

1/28/2026 at 1:32:25 PM

That's not a problem of the platform, but is a problem of the developers.

The extra cost of an Android capable tablet (maybe $200 especially wholesale) is a minimal hardware cost considering the overall price of the equipment is in the thousands.

But finding good embedded developers is a very difficult problem to solve, much easier to find Android app developers and then you get the Android eco-system for free like device management, OTA updates etc.

Put all the sensors and controls on a USB bus and you need one or two actual embedded developers to deal with the drivers and the rest of the developers can build the UI that people see.

In the case of a gym, the person buying the equipment is the customer, not you.

They want features that will make you "sticky" to the gym, plus save costs on training you on how to use the equipment.

by rswail

1/28/2026 at 4:40:53 PM

Cardio units have neither a "weight bar" nor a repetition counter, but they have a whole universe of possible features in the realm of scripted sequences, reactions to HRM signals and even just "making time pass" features. With unbounded gimmickyness, the sky is the limit.

Personally, I'm a bit of an aficionado of close to the metal sports electronics. When I stare at gym screens I immediately notice updates that are supposed to come in once a second to get randomly delayed by what must be hundreds of millis. But I can totally see why they went that route. It's a market where feature quantity is big as a success metric and using a maintenance-friendly platform is even bigger. Wether Android actually checks that box might be debatable, but a bad embedded implementation could easily be worse, no doubt about that.

In the old days, those screens would have randomly dropped into some Windows desktop failing to operate in some kiosk mode fantasy.

by usrusr

1/28/2026 at 8:33:50 PM

And then you start selling in a country which demands accessibility for your equipment. Good luck getting a 20+ language human-sounding TTS system on your ESP32.

by miki123211

1/28/2026 at 10:45:18 AM

If you watch "Microsoft is Getting Rusty: A Review of Successes and Challenges" it appears the whole effort is more on the Azure side, and besides some timid adoption like GDI regions, there is a lukewarm adoption of Rust on Windows side, still pretty much a C and C++ feud.

https://www.youtube.com/watch?v=1VgptLwP588

by pjmlp

1/28/2026 at 12:05:58 PM

> 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?

by palata

1/28/2026 at 5:43:07 PM

We invested a lot into build system optimizations to bring this number down over time, although we did accept on the order of 200 KiB size overhead initially for the stdlib. We initially launched using a Gradle + CMake + Cargo with static linking of the stdlib and some basic linker optimizations. Transitioning WhatsApp Android to Buck2 has helped tremendously to bring the size down, for instance by improving LTO and getting the latest clang toolchain optimizations. Buck2 also hugely improved build times.

by dcsommer

1/28/2026 at 10:49:56 PM

Thanks!

by palata

1/28/2026 at 12:34:40 PM

Probably yes. It's ~300KB per binary, and it's a one-time cost.

It can be avoided entirely by disabling the standard library, but that's inconvenient, and usually done only when writing for embedded devices.

Usually the problem isn't the size directly, but duplication of Rust dependencies in mixed C++/Rust codebases.

If you end up with a sandwich of build systems (when you have library dependencies like C++ => Rust => C++ => Rust), each Rust/Cargo build bundles its copy of libstd and crates. Then you need to either ensure that the linker can clean that up, or use something like Bazel instead of Cargo to make it see both Rust and C++ deps as part of a single dependency tree.

by pornel

1/28/2026 at 2:23:43 PM

The size is not fixed. It changes based on how much of the standard library you use. Dynamically linking the standard library is also a valid option in many cases.

by surajrmal

1/28/2026 at 5:18:22 PM

Posted elsewhere but The default hello world stripped with one codegen unit and panic=abort was 342kB both nightly and stable. Adding lto dropped it 42kB in stable and 40kB in nightly. Adding build-std and only building core did not reduce it any further in size.

by galangalalgol

1/29/2026 at 3:39:21 AM

I agree, but if you use more of the std library it will contribute more to the final image. I can write a 100 line rust file that ends up being 1MiB (even after lto) because I maximize as much code from the standard library as possible. This is not a knock on rust, but your statements can be a misleading as well. In practice most folks ignore the majority of the standard library so only a few hundred kib of std library end up in their binary.

by surajrmal

1/29/2026 at 7:13:44 PM

Bit late, but I made a small program that did network and file io as well as using a variety of containers and running system commands. I couldn't get the default release over 650kB. Using a single codegen unit lto strip and panic=abort got that down to 432kB. Using build-std didn't get it any smaller still. When I added optimization for size was the only way I got build-std to shrink things any further than the other options alone, and that only got me 10kB. My conclusion is that build-std is not a substantial contributor. Using std seems to add 300kB-500kB depending on how much you use. That seems like a lot to me because I am old, but elf binaries add several kB of header so maybe I should stop worrying so much.

by galangalalgol

1/30/2026 at 6:25:20 AM

If you build the standard library as a shared library it will be 4+MiB. The portion of that which you end up using is variable but there are ways to accomplish large usage without a great deal if code. I can get a 1.5 MiB binary down to 500KiB by dynamically linking the shared library. It's a net fun because I have many such binaries so it saves size in aggregate. It really does come down to what subset you use though.

by surajrmal

1/28/2026 at 2:50:01 PM

Can it do lto on stdlib even without the nightly build-std flag?

by galangalalgol

1/29/2026 at 12:22:00 PM

I mean you get one upfront cost for things like allocators, common string manipulation and std::fmt, std::{fs, io, path} helper functions, and gathering of pretty backtraces for panics (which is a surprisingly fiddly task, including ELF+DWARF parsers and gzip to decompress the debug info).

A println!("hello world") happens to pull in almost all of it (it panics if stdout is closed).

Later code growth is just obviously proportional to what you're doing, and you're not getting a whole new copy of std::fmt every time you call print.

by pornel

1/28/2026 at 12:10:26 PM

The whole article a bit watery which is why I read it as a PR rather than technical presentation

by menaerus

1/28/2026 at 9:23:50 AM

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.

by kpcyrd

1/28/2026 at 2:59:55 PM

> "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?

by I_am_tiberius

1/28/2026 at 3:50:54 PM

WhatsApp could exfiltrate messages at the ends. But I assume the trick lies in the word "default". Didn't Skype also default to end-to-end encryption, unless there was a server flag that disabled it for that specific user (I might be fuzzy on the details)

by wongarsu

1/28/2026 at 5:17:48 PM

I don't trust un-auditable client applications...

If you want to assure me your e2e is secure, there must be at least two clients implemented by different people, with at least one of them opensource.

Whatsapp used to have this, but lately they have cracked down on third party clients.

by londons_explore

1/28/2026 at 8:31:43 PM

> Whatsapp used to have this, but lately they have cracked down on third party clients.

Blame spammers on that. The amount of scammers and spammers on Whatsapp is unreal.

by mschuster91

1/28/2026 at 6:08:33 PM

Even if they have, this doesn't prevent from turning on a feature flag, or push an experimental build to some users.

by rvnx

1/28/2026 at 7:38:38 PM

If there is a 2nd opensource client written by someone else, you would hope they would raise the alarm when asked to implement "feature flag 437 means send all the crypto keys to the server".

by londons_explore

1/28/2026 at 3:09:22 PM

Every encryption is end to end if you're not picky about the ends, or metadata.

Do you trust facebook (excuse me, meta) to not snoop on your messages, and to not share them with the "intelligence" agencies ?

by 4gotunameagain

1/28/2026 at 3:31:57 PM

This is not true. The IETF draft is explicit that E2EE means that the message cannot be read by any party other than the sender and the intended receiver. When companies like Meta claim they support E2EE, this is what they claim. There are no tricky semantics or legalese at play here.

by Fripplebubby

1/28/2026 at 4:26:37 PM

To be fair zoom did claim E2EE, with one of the ends being their servers.

by monocasa

1/29/2026 at 11:34:18 AM

Speaking of Zoom and encryption, its crazy that they bought Keybase (I think they basically said it was largely an acquihire) years ago, and have neither shut it down as everyone thought, nor materially changed it in any way. Unless they changed something it even gives 200GB cloud storage (KBFS) iirc.

by morpheuskafka

1/28/2026 at 4:39:00 PM

It's not entirely accurate to say "any party other than the sender and the intended receiver," since the messaging app running on the user's device can read the messages. Something like "any third party (other than the app vendor)" would be more accurate. Without actually analyze app behavior, it comes down to trusting that the vendor doesn't do anything nefarious.

by antonvs

1/28/2026 at 5:22:41 PM

One could imagine a design where even the app vendor is untrusted... You would send an encrypted chunk direct to the GPU, which would then decrypt and render the message text in some secure environment onto the screen.

Neither the OS nor the application would know the contents of your message beyond "it's 500x700 pixels".

Similar things are done for DRM video, and widevine level 1 or 2 haven't seen many breaches despite running on a wide array of hardware open to physical attack.

by londons_explore

1/28/2026 at 6:38:48 PM

Oh it's definitely possible. The (dis)incentives tend to be strongly against such secure systems, though.

by antonvs

1/28/2026 at 11:01:56 PM

In the messaging game, there is every incentive to be seen as the secure-est one.

If you can have an e2e chat between two iphones locked in a big glass box with a sign that says "Anyone who can hack into this conversation gets $100M", that's a really good marketing campaign.

If you can make the app use secure enclaves or whatever to take the ~100k people who write the source code of the libraries, app and OS out of the attack surface, that $100M becomes much safer.

by londons_explore

1/28/2026 at 5:06:58 PM

As far as I remember, Google does the final signing of the APK, which is eventually the signature verified by the OS to verify if an update is valid or not.

So Google can, if ordered or willing to help, create a new release track (e.g. experimental-do-not-deleted) and add specific e-mails to that track with the "improved" version.

Nobody would be able to see that in real world, and you know what, if WhatsApp themselves are ordered, they can also create their own "test" track, it's just less covert but it would technically be working.

In all cases, Google and Apple have to respect US laws, and the laws of earning money too.

If you do not cooperative with intelligence / police services of your country, only bad things can happen.

by rvnx

1/28/2026 at 7:28:30 PM

Yes, the app could be compromised, or the OS, or the compiler of the app, or of the OS, or the OS of the compiler, or the CPU any of these things run on, etc. etc. None of that is relevant to the definition of E2EE.

by mr_mitm

1/28/2026 at 7:56:19 PM

It's relevant to how E2EE is described to users. Representing that it's not possible for anyone other than the sender or recipient to read messages is misleading and just incorrect in general.

A particularly relevant point is when it comes to government interception. E.g. it would be perfectly possible for an messaging app to have a "wiretap mode" that the vendor enables for users that are the subject of a relevant warrant.

by antonvs

1/28/2026 at 5:41:30 PM

> When companies like Meta claim they support E2EE, this is what they claim.

Well, that statement can only resolve to true.

These requests of data collection are perfectly legal. FBI DITU gives an order: give me all chats from *@banana.com and they receive banana.com.

From there, two choices from the perspective of a tech provider:

a) You accept. You get paid.

    You can always claim you had been coerced / are a victim, and that everything has been done by the law.
b) You refuse. It's a crime.

    You take the risk to lose over 250K per day (!) in fines, some other court scandals that will come to you, some shady private stuff (what if we learn about your secret jacuzzi ?), harassement of the team, be publicly shamed that you supported terrorists who caused actual death of Americans, etc.

    In addition, nobody will know that you are the privacy hero and you are not even sure that the data is not exfiltrated another way.
To this day, Apple, Facebook, Google still deny participating in illegal requests. They claim these were lawful requests, that have been carefully looked one-by-one.

Yes, we looked carefully and decided we won't enjoy losing 100M USD and go to jail.

The trick is that the identifier / wildcard can be very vague and wide. Or there can be multiple of them, each of them are narrow, but put one of top of the other they are super wide.

by rvnx

1/28/2026 at 8:35:16 PM

Do companies that claim E2EE support face consequences if they don't abide by IETF's definition? Not like IETF governs them.

by jolmg

1/28/2026 at 8:43:38 PM

> Do you trust facebook (excuse me, meta) to not snoop on your messages

No, but I trust some nosy German guy at TU Whatever to spend hours poking at the assembly, find that hidden flag and proudly present it at 40C3.

With enough eyeballs, all source is open (and AI will give us far more eyeballs than we have any idea what to do with).

Sure, you can have different builds distributed to different people, but the NSA can also just do that with Signal, Signal being open source makes it that much easier. FDroid mitigates this somewhat, but it's not like the NSA can't get a fake TLS certificate for their domain and MITM your communications.

by miki123211

1/28/2026 at 7:45:31 PM

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

by aloukissas

1/28/2026 at 2:10:38 PM

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.

by blub

1/28/2026 at 2:28:11 PM

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.

by surajrmal

1/28/2026 at 4:59:43 PM

I had already said it’s a PR piece, you’re merely rephrasing that and making it sound like a good thing.

This and the Google blogs offer zero technical insights and I haven’t learned anything from any of them.

by blub

1/29/2026 at 3:35:41 AM

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.

by surajrmal

1/28/2026 at 4:32:38 PM

> 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.

by antonvs

1/28/2026 at 4:57:39 PM

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.

by blub

1/28/2026 at 11:57:01 AM

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

by aero-glide2

1/28/2026 at 1:53:38 PM

To be fair the increased reliability of Rust code over C++ isn't just because of memory errors (out-of-bounds accesses, use-after-free, type confusion, etc). You also get:

* No undefined behaviour (outside `unsafe`, which is quite easy to avoid). In C++ there are many many sources of UB that aren't really memory errors directly, e.g. signed integer overflow or forgetting to `return` from a function.

* A much stronger type system.

Those two things have a really significant impact on reliability.

by IshKebab

1/28/2026 at 3:49:26 PM

Rust's "A language empowering everyone..." tagline also helps justify the heavy lifting needed to prevent you shooting yourself in the foot, because we're all able to imagine a hypothetical less experienced programmer who might make a mistake even as we swear that we'd never make it ourselves.

by tialaramex

1/28/2026 at 12:33:34 PM

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

by mentalgear

2/3/2026 at 9:06:22 PM

[dead]

by yasmineroy33

1/28/2026 at 12:16:46 PM

[flagged]

by wrtc_dev

1/28/2026 at 2:09:20 PM

That's right, Signal (https://kerkour.com/signal-app-rust), Proton (https://kerkour.com/proton-apps-rust), Matrix, Wire and many more are using a share, cross-platform Rust core and a platform-dependent UI layer.

But it's not only the security-critical paths, but also most of the business logic (see the 2 posts above).

by randomint64

1/28/2026 at 1:21:12 PM

I agree with everything you say. But wow, does that comment sound like AI. Probably Grok?

Not saying you are AI, you might just be a heavy user who picked up the same patterns

by wongarsu

1/28/2026 at 1:59:11 PM

If it were an old account I might have given them the benefit of the doubt, but they literally just joined to make this comment. There's so many green accounts popping up which reek of AI now, like I've seen ones where all of their comments are almost exactly the same length.

by jsheard

1/28/2026 at 2:33:49 PM

It's a brand new account that reads 100% like a ChatGPT response where the author just swapped out the em dashes for hyphens when posting, knowing it's a common "indicator" people look for.

It's more surprising to me that it seems to have already fooled a bunch of people looking at their replies to you.

by rob

1/28/2026 at 1:22:13 PM

I like your AI slop detector, is it part of your consciousness ?

by m00dy

1/28/2026 at 1:35:11 PM

The "is key - ", is a key giveaway.

EDIT to expand the evidence: It's placing unnecessary emphasis on a one off mention in the article (differential fuzzing) and then writes a bunch of bullshit around what it thinks it means (it's wrong, differential fuzzing isn't running them both in parallel during a transition, it's a testing methodology based on inputs/outputs).

by candiddevmike

1/28/2026 at 1:50:14 PM

Which many people use. Heck, go to Stack Overflow about 10 years back. You will see people using it. It's a style.

by braiamp

1/28/2026 at 2:00:45 PM

TIL I'm an AI

by seritools

1/28/2026 at 2:04:32 PM

I think it's a giveaway that it's human! A hyphen is incorrect punctuation.

by jdxcode

1/28/2026 at 2:12:45 PM

According to British style guides an en-dash would be correct in that usage, and the difference between an en-dash (–) and a hyphen (-) is pretty small. Seems perfectly defensible to me unless you are publishing a book or academic journal

by wongarsu

1/28/2026 at 2:37:09 PM

AI is trained on human output, so that's not really a good differentiator.

by dewey

1/28/2026 at 2:58:06 PM

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

by happyweasel

1/28/2026 at 3:35:47 PM

Oh come on, that was funny. It also highlights a problem with the way people write rust. If your app panics it has a bug. People throw panics in cases that can absolutely happen, a file isn't there or fails to parse, some set of inputs is mutually inconsistent these are things for error checking. Even if the correct way to handle an error you detect is to stop the app, do that instead of panicking. Panics are for things that should be impossible. Ideally they even get optimized out.

by galangalalgol

1/28/2026 at 4:37:09 PM

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.

by justinlords

1/28/2026 at 4:58:25 PM

We really need an AI filter here on HN.

by chinathrow

1/28/2026 at 5:34:02 PM

A comment like this works as well, let the community do its thing.

by stingraycharles

1/28/2026 at 6:11:25 PM

There are a couple of bots here.

Quoting a user:

    keeping it simple: a flat $15,000 to get you on the front page of Hacker News.
    [...] contact e-mail below
Expensive, but now with LLMs it's super cheap to do.

Spend a week to do a bot, get 10'000 USD of ARR for your B2B tech SaaS, and applause from your investors.

And a week is probably exaggerated, 2 days max

by rvnx

1/28/2026 at 9:16:20 PM

Do you have any actual evidence that these types of services are being offered for that type of price point, though?

The reason I'm asking is that I actually believe the price point is much lower. It's probably much easier to get on the front page of HN of you time the submission + upvotes well enough.

by stingraycharles