Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Async/await in no_std rust was a godsend for embedded firmware and driver development, turning really simple and linear code into a tiny state machine with zero alloc and no runtime cost. I can imagine how coroutines could provide similar for C++.

I migrated a rust LoRa driver from traditional blocking to async/await in order to test two modules in simultaneous send/receive mode as part of the test suite on a single STM32 chip. Aside from pleasing the HAL abstraction by bubbling all the generics throughout, it was an entirely pleasurable experience and made much better use of available resources than the traditional approaches without having to manually manage state across yield points or use a dynamic task scheduler. No OS, no runtime, no manual save/restore of stack, no global variables. It is really the future of the truly micro barebones embedded development.



I thought async/await creates a state machine in the background. If so, there should be a runtime cost.

State machines to deal with interrupts (to name the most basic kind of async event) is the ABC of embedded "bare metal" programming.

Whether async/await is cleaner, easier, readable, etc. is a matter of taste.


No, it compiles to a state machine (there is no “background”) and you just loop over the fixed list of futures/tasks in your main calling next/poll() to step through the states - there is no runtime so you have to do that yourself.


Yes, "compiles to state machine" is what I meant.

> you have to do that yourself

Yes. And it has a cost. Plus the cost of executing that state machine (changing states, etc.), which is hidden from you.

One can always pull a more optimized and fine-tuned state machine made by hand (sitting on WFI for example), and here comes the "taste" factor.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: