4 ms·
Rust has settled into an excellent design niche where the language does not provide any features that require a language runtime. Rust's async/await is a purel
by wyager 2y ago
Rust has settled into an excellent design niche where the language does not provide any features that require a language runtime.
Rust's async/await is a purely compile-time feature, with no runtime support required.
This is extremely powerful because it means you can do things like easily run async code on embedded devices with no OS.
To run async code in rust, you bring your own executor. The most popular one is tokio (for desktop OSs), but you also have stuff like pollster (for running async code as blocking code) and embassy or RTIC (for embedded).
- jtrueb 2y agoAgreed, as much as there are complaints about usability of async in Rust, many alternatives proposed would fail in resource constrained systems. Green threading would be impossible or very limiting on embedded, where each stack eats away at something like 1-2% of memory and allocation is likely impossible or prohibitively expensive. I do note that some of the futures are starting to take up a couple KiB of RAM and ROM.
- eknkc 2y agoI might be completely wrong as I only played with rust but the current method seems to couple any async libraries you’d like to write to the executor. Which feels wrong imo. Would it be feasible to provide async io (file, network) code in std and let the executors execute? Or even some std traits that abstract the filesystem, network etc so that the executors can bring their own implementations but at least library code could only depend on std?
- wyager 2y agoCorrect, libraries do have to either pick a specific async IO library or use a trait for async IO. I have seen some of the latter in embedded-land, although I'm not sure if it's used in desktop async rust as well. The rust compiler currently discourages async traits with a warning, which seems wrong to me, but we use them extensively in embedded anyway.
- anonymoushn 2y agoThe feature is less than 1 year old, so a lot of the ecosystem couldn't use the feature because of being written before the feature existed. It does seem silly to have a warning today.
- anonymoushn 2y agoThis is a fine approach but it's trivial to ship green threads with no runtime support as well. Various libraries implementing the feature exist for C or Zig etc.
- kbolino 2y agoIf you can accept cooperative scheduling that runs tasks only on a single core, then yes, lightweight solutions exist. This is more like "event-driven coroutines" than "green threads" though. If you want "full" green threads with preemptive scheduling and parallel execution across multiple cores, then an active runtime is needed.