getrandom VS embassy

The crypto source in Go is great, no complaints there. Lints like gosec even recommend using it when generating crypto entropy. Go did a good job here, and I expect Rust will do the same sometime after getrandom reaches 1.0 so the API questions are settled, plus whatever makes sense for the future-proofing the standard library needs.

I would wait for the getrandom crate to reach 1.0, which will answer many of the questions around what an API like this can look like, and then maybe the standard library discussion will be on firmer footing because at least we'll know what API we want to immortalize. Rushing that now just to save people importing a small crate does not seem to be the way to go.

I'd caution against using /dev/random directly, and instead recommend using getrandom. It's effectively the same thing on Haiku and Redox, but is cross-platform and will upgrade to better sources on various platforms as available (such as using the getrandom() call on Linux and Android, or getentropy() on macOs, if avaialable).

getrandom

It's a default, but overwritable behavior, see the #[path] attribute. You still have to create N files for each supported platform, but at the top level you will see only one module. On of the crates which uses this approach in practice is getrandom.

IIUC the main problem which prevents from moving HashMap & co to alloc is lack of API to get system entropy which is required for DOS protection. Ideally we would have a #[global_allocator]-like functionality for retrieving system entropy. Relevant issue: https://github.com/rust-random/getrandom/issues/21

thanks. looked that up. for the curious: https://embassy.dev/

Running the Embassy RP2040 USB CDC ACM serial example takes about 5 seconds on a Pico.

https://github.com/embassy-rs/embassy/blob/main/examples/rp/...

Async solves different problems, you can, for instance, have just a single-threaded CPU and still have a nice API if you have async-await. It might not be so cool at a higher level as Go's approach of channels and threads, but it's cool in embedded, read this:

https://github.com/embassy-rs/embassy?tab=readme-ov-file#rus...

"Rust's async/await allows for unprecedently easy and efficient multitasking in embedded systems. Tasks get transformed at compile time into state machines that get run cooperatively. It requires no dynamic memory allocation, and runs on a single stack, so no per-task stack size tuning is required. It obsoletes the need for a traditional RTOS with kernel context switching, and is faster and smaller than one!"

I'm just toying with Raspberry Pi Pico and it's pretty nice.

Go and Rust have different use cases, the async-await is nice at a low level.

I have not yet dipped by toes in the Rust waters, but reading about the embassy project is actually what piqued my curiosity about using C++ coroutines in embedded. Are you familiar with the project or have you found it lacking?

I think I get the basics (shoutout to the Rust Embedded Working Group!), and I've started looking for the stack I'd be using. I think Embassy is really amazing, as well as the work of the ESP team -- hats off.

> }

And this is how to do it using embassy, which is an async framework for embedded in rust:

https://github.com/embassy-rs/embassy/blob/main/examples/rp/...

> not good for embedded

embassy begs to differ

https://embassy.dev/

async/await is really just a syntax for building state machines in a way that resembles regular code. It's compiled down to the same code that you would write by hand anyway (early on it had some bloat in state size but I think it's all fixed now).

And embedded has a lot of state machines!

You can run multiple executors at different interrupt priority levels (with multiple tasks per executor), which allows tasks on the higher priority executor to interrupt other tasks. Here's an example https://github.com/embassy-rs/embassy/blob/main/examples/nrf...