4 ms·
I notice this as well; there is a false dichotomy of "Async/Await" or "blocking". I see this in embedded too. I think a lot of rust embedded programmers learned
by the__alchemist 2y ago
I notice this as well; there is a false dichotomy of "Async/Await" or "blocking". I see this in embedded too. I think a lot of rust embedded programmers learned on Embassy, and to them, not using Async means blocking.
- omani 2y agocan you elaborate on this?
- the__alchemist 2y agoWriting programs that perform multiple tasks asynchronously can be done in many ways. It is a broad and important tool in software, and the Async/Await language is only one way to do it. Examples: - Multiple cores - DMA or other dedicated hardware - GPU programming - Distributed systems (e.g. the CAN network in your car) - Threads - Interrupts - Event loops - Coroutines
- zavec 2y agoIs the alternative the more traditional spawning threads and using channels, or is there another paradigm? That's definitely something I'd be interested in learning more about.
- onjectic 2y agoI think they mean that there is more than one asynchronous paradigm. Actors is one alternative I can think of.
- palata 2y agoWhere an actor has its own thread and communicates with a channel, right?
- pdimitar 2y agoNot necessarily, a lot of actors can be sharing the same OS thread and be preemptively switched away from when they hit a certain limit of instructions or start an I/O call. Erlang demonstrates this very well because it works there without a glitch 99.99% of the time (and the remaining 0.01% are because of native code that does not yield control).
- GolDDranks 2y agoThere is also readyness-based polling in a loop, without the async/await sugar.