4 ms·
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 t
by sophacles 3y ago
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.
- 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).