[oddmiral]

It is not designed for, but Rust works well on microcontrollers, such as Arduino. For example, a blink program for Arduino in Rust is less than 300 bytes in size when compiled with "s" optimization level. It's a bit larger than C because of vector of interrupt handlers and error handling.

[steveklabnik]

> It is not designed for,

Making sure Rust can work in embedded environments is absolutely a design goal, and choices around this are made explicitly.

[tester756]

>choices around this are made explicitly.

e.g?

[steveklabnik]

A few off the top of my head: the core/std split, making the core language never allocate implicitly, the design of async/await.

[worik]

> the design of async/await.

I am curious

How is "the design of async/await." for embedded programming?

[steveklabnik]

The design of async/await took "using it in embedded" as a constraint. This is why it doesn't allocate, for example. Even C++ coroutines have one allocation, though they say that it can often be optimized away.

This means RTOS-like projects can use it for tasks, and it works well. Embassy is an example of such a project.

(Yet, I should also point out that you don't have to: at work we keep ours synchronous, for Reasons. Rust lets you do what you want.)

[Vecr]

Async/await does not require dynamic memory allocation.