How to think about `async`/`await` in Rust

Re:How to think about `async`/`await` in Rust by Animats on Wednesday July 05, 2023 @03:20AM (#36596783)

There's a role for async, and it's when you're very I/O bound, you have one thread, and async means you don't need locking. This is simple to think about. That's the classic JavaScript model.

If you have compute-bound components, things get more complicated. If you have threads, locks, and async, all in one program, things get much more complicated. I'm not sure that's a win. At some point, it's easier to use something like Go's green-thread "goroutines", which try not to block, but can block if they have to.

[ Parent | on HN ]

Re:How to think about `async`/`await` in Rust by starcraft2wol on Wednesday July 05, 2023 @12:49PM (#36603124)

> when you're very I/O bound, you have one thread

Yes, but this is very unusual. In a web server, you have pool of threads that can respond to incoming connections. When one is blocking, another is ready to go. All the transition are handled transparently by the kernel.

[ Parent | on HN ]

Re:How to think about `async`/`await` in Rust by Animats on Wednesday July 05, 2023 @02:12PM (#36604607)

In node.js, each process used to be single thread. There's now a hokey threading model with limited shared memory areas.[1] Annoyingly, this is also Android's threading model.

[1] https://nodejs.org/api/worker_threads.html

[ Parent | on HN ]