> Looks nice and has good ideas. But what's the benefit of this over just using > threads? Cooperative scheduling is bug-prone much like multi-threading is > IMHO without its performance benefits.
Cooperative scheduling/fibers and threads are orthogonal. Threads are handled at the scheduler level. The fastest multi-threading runtime I have seen actually uses fibers, similar to `NimGo`, see: <https://github.com/chaoran/fibril> And in particular the stack switching: * <https://github.com/chaoran/fibril/blob/9991aac/src/fibrili.c#L18-L27> There are many reasons not to use fibers: see C++c oro author criticism - <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1364r0.pdf> but performance is not one of the reasons. Debugging and control-flow obfuscations (i.e. exception incompatibility), the need of assembly, and mmap-ing a memory region as executable (i.e. large attack surface) are more problematic.
