What's interesting is the broader trend: Signal's libsignal is Rust, Matrix's vodozemac (Olm/Megolm implementation) is Rust, and now WhatsApp is moving this direction. The industry seems to be converging on Rust for the security-critical paths while keeping the UI layer in whatever makes sense for the platform.
The differential fuzzing approach they mention is key - you can't just rewrite and hope for the best. Real-world media is full of edge cases and malformed files that users expect to "just work." Having both implementations running in parallel during the transition gives you a safety net.
Not saying you are AI, you might just be a heavy user who picked up the same patterns
They don't say what they did about it, do they? Did they just accept it?
https://github.com/facebook/buck2/commit/4a1ccdd36e0de0b69ee...
https://github.com/facebook/buck2/commit/bee72b29bc9b67b59ba...
Turn out if you have strong control over the compiler and linker instrumentations, there are a lot of ways to optimize binary size
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.
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?
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.)
If you also add in the extra ease of things like device management across fleets etc, it becomes a no-brainer for the manufacturer.
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.
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.