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.
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.
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.
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.
Wasn't there news lately that they can still read your messages somehow?
Do you trust facebook (excuse me, meta) to not snoop on your messages, and to not share them with the "intelligence" agencies ?
* 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.
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.
But it's not only the security-critical paths, but also most of the business logic (see the 2 posts above).
Not saying you are AI, you might just be a heavy user who picked up the same patterns
It's more surprising to me that it seems to have already fooled a bunch of people looking at their replies to you.
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).