Live data from Hacker News

Rust at Scale: An Added Layer of Security for WhatsApp

engineering.fb.com

21–30 of 151 posts

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#21
post #18
post #14

Earlier quoted context omitted.

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.

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.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#22
post #12

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

I suspect they just use no_std whenever its applicable

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

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#24

[flagged]

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

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

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#25
post #10
post #8

Earlier quoted context omitted.

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. It's like complainin…

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.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#26
post #21
post #18

Earlier quoted context omitted.

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

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.

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#27

[flagged]

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

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

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#29

Earlier quoted context omitted.

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

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

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

Re: Rust at Scale: An Added Layer of Security for WhatsApp

#30

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

Post reply on HN