4 ms·

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

by nevi-me 9mo ago

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

marisen 9mo ago
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)
- deleted 9mo ago
  [deleted]
- pjmlp 9mo ago
  Like our gym devices that have a full tablet to run a basic application to control weights, talk about wasting money.
  - g947o 9mo ago
    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.)
    - pjmlp 9mo ago
      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.
      - usrusr 9mo ago
        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.
        pjmlp 9mo ago
        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.
        rswail 9mo ago
        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.
        usrusr 9mo ago
        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.
- charcircuit 9mo ago
  >deployed more than WhatsApp If you count old Android versions before Rust was added.
- fabrice_d 9mo ago
  WhatsApp was using libsignal (the C version) when I worked on the KaiOS integration in 2017/2018.
pjmlp 9mo ago
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 https://www.youtube.com/watch?v=1VgptLwP588

by nevi-me 9mo ago

marisen 9mo ago

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)

deleted 9mo ago
[deleted]
pjmlp 9mo ago
Like our gym devices that have a full tablet to run a basic application to control weights, talk about wasting money.
- g947o 9mo ago
  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.)
  - pjmlp 9mo ago
    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.
    - usrusr 9mo ago
      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.
      - pjmlp 9mo ago
        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.
        rswail 9mo ago
        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.
        usrusr 9mo ago
        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.
charcircuit 9mo ago
>deployed more than WhatsApp If you count old Android versions before Rust was added.
fabrice_d 9mo ago
WhatsApp was using libsignal (the C version) when I worked on the KaiOS integration in 2017/2018.

pjmlp 9mo ago

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 https://www.youtube.com/watch?v=1VgptLwP588