This article is a nice addition to the community since rarely is a complete rewrite of a firmware corpus possible. Speaking of Rust and host or boot firmware, the recently published https://techcommunity.microsoft.com/t5/surface-it-pro-blog/s... provides a nice experience report. Other work on moving Rust into EDKII for UEFI style firmware https://github.com/tianocore/edk2-staging/tree/edkii-rust is described in https://uefi.org/sites/default/files/resources/Enabling%20RU... and https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resour.... There's also guidance on Rust for firmware in a book chapter https://link.springer.com/chapter/10.1007/978-1-4842-6106-4_....

It's really cool that google is investing so heavily in rust. However, the blog post is more of a "starting point" than a "lessons learned" (which I hoped for).

I hope this effort can also translate into more Rust in Linux, rather than potentially Android on a different OS.

https://archive.is/HitH8

The most painful thing about this is strings. To convert to/from cstrings, you have to use the stdlib FFI function, which will allocate memory. This was a nice surprise in the form of a bunch of undefined GNU ABI references when linking to C. I was writing bare metal firmware. I hadn't imported libgcc or even libc yet. Having to convert every string and use unsafe blocks everywhere is a pain. And last time I tried it wasn't even possible to interface with a varargs function. Im not a big Zig fan but it looks so much better from a FFI perspective. I haven't tried it but it looks like everything just works.

Uh, I get a mostly blank page with a randomly-placed YouTube icon on the right, and no actual text? Wut?

Edit: Firefox on Linux/x64.

Too bad they do not go deeper into impacts on binary image size.

This page came up for me blank...

I had to stick it in brave for it to work. I guess google doesn't make web pages anymore...