Hacker News Reader

Comment by the__alchemist | Hacker News Reader

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.

View on HN

Is 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.

I think they mean that there is more than one asynchronous paradigm. Actors is one alternative I can think of.

Where an actor has its own thread and communicates with a channel, right?

Not 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).

There is also readyness-based polling in a loop, without the async/await sugar.

can you elaborate on this?

Writing 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

Reply on news.ycombinator.com