4 ms·
>Not specific to rust, but I think asynchronous programming in general is a hype. Hmm, wasn't the whole point of doing things in event loop because it way out
by vmfunction 3y ago
>Not specific to rust, but I think asynchronous programming in general is a hype.
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.
- arijun 3y agoThe 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.
- sophacles 3y agoUntil 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.
- gpderetta 3y agoStackful 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).