Re:How to think about `async`/`await` in Rust
by arijun on Wednesday July 05, 2023 @04:33AM
(#36597470)
The parent comment mentions green threads. While there is some performance hit to using them, I don’t think it is way less performant. I mean, go was built for being a web backend, and is based on green threads.
For rust specifically, though, green threads/coroutines were discarded because they are not zero-cost.
Re:How to think about `async`/`await` in Rust
by sophacles on Wednesday July 05, 2023 @05:53PM
(#36607689)
Until go 1.14 it basically the same as any other async/await under the hood. Every function call included an implicit .await - that is it offered a `yield` to the runtime scheduler. All the io was built around non-blocking/polling, etc. Tight loops in go would potentially screw up your app performance because there were no yields. In 1.14 they introduced some sort of preemption for tight loops too.
Re:How to think about `async`/`await` in Rust
by gpderetta on Wednesday July 05, 2023 @06:57PM
(#36608371)
Stackful vs stackless, that's the big difference and the point of the original comment. Stackful abstractions are strictly more powerful of stackless ones (go coroutines subsume async/await but not viceversa).
You can have good ergonomics and performance with stackful cooperatively scheduled tasks instead of a stackless sync/await abstraction.
Async/await makes sense when you have so many tasks that you cant afford to dedicate a full stack to each of them and segmented stacks or heap allocated frames are not an option (for performance or compatibility).
Hmm, wasn't the whole point of doing things in event loop because it way out perform thread-based architecture? Like when Nginx way out performs Apache? On a single core CPU of course.
Edit: It is not that event-loop is better than thread-based, just in a web server scenario it just perform much better.