> over 3 billion people to message securely each and every day.<p>Whatsapp is a chat application with 3 billion daily active users.<p>For those of you in the US (where Whatsapp is seldom used), this is a fact worth remembering.<p>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.
What one should do about this? I mean, beside working on lowering that number.<p>(Asking as a European who quite stubbornly refuses to install it - there are dozens of us. Dozens!)<p>Edit: please don't participate in making WhatsApp even more inescapable as it is today.
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
Advocate protocols over platforms. Have your government take an active interest in opening up closed communication systems and mandating third-party client access.
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.<p>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.<p>If any Whatsapp employee reading this can look into my WBA Account 1117362643780814
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.
Network effect is killer. "better" would include having more than 3 billion people already on it.<p>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.<p>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.
> Network effect is killer. "better" would include having more than 3 billion people already on it.<p>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.<p>It has happened before, and as long as new regulation doesn't solidify Whatsapp/FB in their position, it can happen again :)
WhatsApp happened at a time when, in Europe, you paid for SMS.<p>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.<p>To overcome it now, you need a lot more effort (or rely on enshittification, which I'm sure will happen).
No, before Whatsapp, people were mostly using Facebook messages, at least where I lived at the time.<p>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.<p>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.
Make your customer support on whatsapp. "Drop us a message to change your order". Allow ordering/enquiries over whatsapp.<p>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.<p>Obviously make sure all URL's have info cards properly rendered in Whatsapp for good share-ability.
Can you describe your reasons? I haven't developed an opinion as no one here uses it.
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.<p>Meta is also a despicable company, they don't need my help to succeed.<p>(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)
Sure, but like with most things, maybe like 200 million max of them in NA/EU would actually bring in real money.
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.
> We believe that this is the largest rollout globally of any library written in Rust.<p>I think that crown currently goes to <a href="https://github.com/googlefonts/fontations" rel="nofollow">https://github.com/googlefonts/fontations</a> which is included in Chromium, not sure if it's on all platforms yet.
Moreover, the translative dependencies of Fontations (click through <a href="https://crates.io/crates/fontations/0.3.0/dependencies" rel="nofollow">https://crates.io/crates/fontations/0.3.0/dependencies</a>) should have an even (slightly) larger install-base.<p>EDIT: from the quote you can also gather that they don't use <a href="https://github.com/signalapp/libsignal" rel="nofollow">https://github.com/signalapp/libsignal</a>
Just for reference, Wamedia ships on the major Meta apps and on iOS, Android, Desktop, and Web platforms.
Just a few more Rust libraries we've shipped in Chromium:<p>- <a href="https://github.com/image-rs/image-png" rel="nofollow">https://github.com/image-rs/image-png</a><p>- <a href="https://github.com/webmproject/CrabbyAvif" rel="nofollow">https://github.com/webmproject/CrabbyAvif</a><p>- <a href="https://github.com/RCasatta/qr_code" rel="nofollow">https://github.com/RCasatta/qr_code</a><p>- <a href="https://github.com/unicode-org/icu4x" rel="nofollow">https://github.com/unicode-org/icu4x</a>
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.<p>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.
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.
> We believe that this is the largest rollout globally of any library written in Rust.<p>I suppose this is true because there's more phones using WhatsApp than there are say Windows 11 PCs.<p>Given that WhatsApp uses libsignal, is it safe to assume that they haven't been using the Rust library directly?
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)
>deployed more than WhatsApp<p>If you count old Android versions before Rust was added.
Like our gym devices that have a full tablet to run a basic application to control weights, talk about wasting money.
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.<p>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?<p>(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.)
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.<p>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.
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.<p>If you also add in the extra ease of things like device management across fleets etc, it becomes a no-brainer for the manufacturer.
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.
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.
Except all the machines have the same feature set I mentioned.<p>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.
That's not a problem of the platform, but is a problem of the developers.<p>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.<p>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.<p>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.<p>In the case of a gym, the person buying the equipment is the customer, not you.<p>They want features that will make you "sticky" to the gym, plus save costs on training you on how to use the equipment.
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.<p>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 <i>why</i> 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.<p>In the old days, those screens would have randomly dropped into some Windows desktop failing to operate in some kiosk mode fantasy.
If you watch <i>"Microsoft is Getting Rusty: A Review of Successes and Challenges"</i> 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.<p><a href="https://www.youtube.com/watch?v=1VgptLwP588" rel="nofollow">https://www.youtube.com/watch?v=1VgptLwP588</a>
> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...].<p>They don't say what they did about it, do they? Did they just accept it?
I suspect they just use no_std whenever its applicable<p><a href="https://github.com/facebook/buck2/commit/4a1ccdd36e0de0b69ee185fc9dae8c9d9dfdf3de" rel="nofollow">https://github.com/facebook/buck2/commit/4a1ccdd36e0de0b69ee...</a><p><a href="https://github.com/facebook/buck2/commit/bee72b29bc9b67b59ba775ce65057f122c75aa70" rel="nofollow">https://github.com/facebook/buck2/commit/bee72b29bc9b67b59ba...</a><p>Turn out if you have strong control over the compiler and linker instrumentations, there are a lot of ways to optimize binary size
Probably yes. It's ~300KB per binary, and it's a one-time cost.<p>It can be avoided entirely by disabling the standard library, but that's inconvenient, and usually done only when writing for embedded devices.<p>Usually the problem isn't the size directly, but duplication of Rust dependencies in mixed C++/Rust codebases.<p>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.
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.
Who knows what they did, but there are things which can be done: <a href="https://github.com/johnthagen/min-sized-rust" rel="nofollow">https://github.com/johnthagen/min-sized-rust</a>
The whole article a bit watery which is why I read it as a PR rather than technical presentation
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.
> "WhatsApp provides default end-to-end encryption for over 3 billion people".<p>Wasn't there news lately that they can still read your messages somehow?
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)
I don't trust un-auditable client applications...<p>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.<p>Whatsapp used to have this, but lately they have cracked down on third party clients.
Every encryption is end to end if you're not picky about the ends, or metadata.<p>Do you trust facebook (excuse me, meta) to not snoop on your messages, and to not share them with the "intelligence" agencies ?
Quite impressive, I did not know so many bugs were due to memory access.
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 <i>also</i> get:<p>* No undefined behaviour (outside `unsafe`, which is quite easy to avoid). In C++ there are <i>many many</i> sources of UB that aren't really memory errors directly, e.g. signed integer overflow or forgetting to `return` from a function.<p>* A much stronger type system.<p>Those two things have a really significant impact on reliability.
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.
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.<p>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.<p>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 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.
> The interesting aspects, such as how they protect against supply-chain attacks<p>There are standard techniques to help manage this that apply across languages, there's no reason to reinvent that wheel.<p>> My hope’s that AI gets really good at Rust so one doesn’t have to directly interact with the unergonomic syntax.<p>"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.
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.<p>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.
[flagged]
That's right, Signal (<a href="https://kerkour.com/signal-app-rust" rel="nofollow">https://kerkour.com/signal-app-rust</a>), Proton (<a href="https://kerkour.com/proton-apps-rust" rel="nofollow">https://kerkour.com/proton-apps-rust</a>), Matrix, Wire and many more are using a share, cross-platform Rust core and a platform-dependent UI layer.<p>But it's not only the security-critical paths, but also most of the business logic (see the 2 posts above).
I agree with everything you say. But wow, does that comment sound like AI. Probably Grok?<p>Not saying you are AI, you might just be a heavy user who picked up the same patterns
If it were an old account I might have given them the benefit of the doubt, but they literally <i>just</i> 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.
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.<p>It's more surprising to me that it seems to have already fooled a bunch of people looking at their replies to you.
I like your AI slop detector, is it part of your consciousness ?
The "is key - ", is a key giveaway.<p>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).
Which many people use. Heck, go to Stack Overflow about 10 years back. You will see people using it. It's a style.
TIL I'm an AI
I think it's a giveaway that it's human! A hyphen is incorrect punctuation.
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
AI is trained on human output, so that's not really a good differentiator.
Cool - now we only need to get selling-you-out-for-profit-Zuckerberg out of WhatsApp to make it really trustworthy.
Let's see how this unwrap()s in production scnr
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.
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.<p>On binary size, static linking with LTO should handle most of the bloat without needing custom stdlib builds.