A nice material, thanks.

I'm using the Rust for my weekend projects and have to say, that this is a very poor choice for the low-level embedded software, you know. :-) At least in the area of the baremetal and, probably, RTOS-supported applications.

The thing is its primary "feature" called the "memory safety" creates too much obstacles when addressing the hardware resources or shared memory locations. There are certain workarounds, like the unsafe regions you mentioned, but they bloat the code. A simple application running at the something like Cortex-M0 will have absolutely no benefits and it will definitely reduce the readability of the code base. And such primitive applications developed by countless vendors somewhere in Asia comprise a significant part of the market by the gross device count.

Moreover, I have a strong feeling that "memory safety" turned into some sort of the marketing motto. Especially if being applicable to the embedded area. Let's address the "Use-after-free" scenario. Again, the majority of the small embedded applications perform only one distinct function. And a well-designed one engages the static allocation only. So there is no room for the dynamic memory, and hence the "use-after-free". Something like uninitialized local variables or pointers definitely remains, and Rust does make them vanish, but again. It is a small device and should be well-tested before going to market. And if not, nothing will save it regardless of what is used to write the software: Rust, C or Ada. It simply crumples.

So I believe that the forced injection of Rust will just fragmentize the development: in the lower end C will prevail, while on the high ground, Rust, supported by Linux or other advanced OSs, will thrive.

Anyway, attempting to create "something the same across all domains", a "swiss knife" for any situation, usually leads to the solution, which does everything equally badly.

Regardless the medical devices, where safety means all, the accelerated transition to Rust may create an isolated environment detached from the rest of the C/C++ world. That may potentially yield problems when hiring and training the personnel, as well as importing some third-party code.

But it is just my humble opinion. Maybe I'm completely wrong and the "Brave New Rust World" is just around the corner. We will see that in the future. :-)

Hi Milica, would you please suggest some books or website tutorial to start learn Rust with a strong background of C langue for with microcontroller like STM32 or PIC32? Thank you.

Thanks for an insightful presentation Milica. I was wondering based on your professional experience with embedded Rust on microcontrollers whether you tend to resort to async with an executor (not sure if embassy is the defacto) or more of an RTOS + Rust type of solution. In general, I wonder if you had any input on what approaches may be more ergonomic when considering professional Rust embedded development.

I didn't know that unit tests are a part of Rust's standard library. I guess it's not the only language that has this feature, but having dealt mostly with unit testing in C/C++ for the past year, this sounds really nice. Great talk. Thank you!

Excellent presentation!