@mratsim Thanks for having taken the time for your very detailed and informative response. Your knowledge and research are very valuable and far beyond mine. I have read with interest your work and must admit some are beyond my comprehension, and I look forward to see your weave-io baby born. However it looks like we have both a diverging opinion and won't be able to convince each other.
However I would like to refocus the subject on those different questions : * What are the flavors of stackful coroutines and which one does NimGo choose ? * Should we avoid to use stackful coroutines (particularly the flavor of NimGo) ? * Should we avoid to use NimGo ? * Is stackless coroutine a better alternative ? ### What are the flavors of stackful coroutines and which one does NimGo choose ? NimGo uses the term Go because it sounds appealing and Go is what probably people should be familiar with. However, both in its implementation and API, they have almost nothing in common when we look closer. In fact, NimGo is internally very close to Lua's Coroutines (it offers a public API to use it directly without the dispatcher). About Go: * It uses a M:N model, where multiple coroutines jobs are dispatched into multiple threads * Its functions have their own calling convention * It uses a growable stack managed by Go's runtime About NimGo: * It uses a 1:N model, where multiple coroutines must be confined into only one thread * it uses C-compliant conventions (nimcall, closure and cdecl internally) * it has a growable stack managed by the system (virtual memory, internally it looks like a fixed stack) * Please also note, that NimGo doesn't use windows' fibers (I don't know about Go) Those design choices have both good and bad i won't go in depth, but the NimGo coroutine model is simpler. And some drawbacks you mention are specific to Go's design choices. ### Should we avoid to use stackful coroutines (particularly the flavor of NimGo) ? I didn't implement at the low level NimGo's memory model. It is build upon minicoro.h, which is a well popular and well tested implementation that have been used in different libraries in C, C++ and is a pillar of the Nelua language (by the same author).Stackful coroutines usage is not popular, but has been succesfully deployed and used in production software and language (Go of course, Lua, boost:asio for c++, and greenlet in python). Considering calling convention, I'm not aware of any problem to use C function whenever your stack pointer is on the heap or not. Although Minicoro.h guard against C++ exceptions usage, some implementation have succesfully used it, and I see nothing preventing NimGo to have a complete working exception handling in Nim. So I think this is a perfectly viable option. ### Should we avoid to use NimGo ? Yes, for now. This is still a new and fresh project, proposition, with an unstable API. I'm pretty sure windows won't yet work and I cannot guarantee ORC will work correctly. There are also a way to go to see if exceptions works correctly, and so much more. Hopefully this project has already a state of usability. This is not a paper project, but something I need and I will built upon for other projects I have. So it will be tested, used and refined. ### Is stackless coroutine a better alternative ? Of course, we love the world better, but Stackful coroutines, CPS and asyncdispatch are so different that I don't think we are really competitor, I just want to makes people angry ;-) Nah!. Firstly std/asyncdispatch. It is already a good, solid and proven alternative to do async. It is flexible and allows to adopt a wide style of programming technique. I won't develop on its drawbacks. IMHO C++'s coroutines looks to me very close to std/asyncdispatch. Secondly CPS. It is an innovative way to do async, unfortunatly a very niche one (although like "fibers" it is not so young). Most of my research on this subject points to deadends where practical usage looked either very complicated or a variant of callbacks. It also seems to impose a style of programming and personally I prefer imperative over functional. I also would love to see how some common example patterns of async could look like under CPS lens (even in a pseudo API). But maybe soon, everybody will use CPS style, makes obsolete other async methods, and this adoption will also make its concept simpler (like standard async which is hard to learn for newbies, but rapidly become instinctive). For now, it not only lakes adoption, but also good library to use it. But I really hope this will change and it could put under the spotlight Nim language as the new hot language to push this style of programming beyond others. I'm not the most qualified person to speak about CPS, about what it fits more, or its drawbacks. I think it should deserves its own topic.
