Thanks Araq, I appreciate the compliment. Being quite novice programmer, "looks nice" and "has good ideas" is quite a lot :-)
Threads are really nice for CPU bound tasks, but very limited for I/O bound tasks for multiple reasons : * You reach rapidly a limit with the number of threads you can spawn * It uses more memory * Its context switch is costly * There is some boilerplate to share data, especially GC memory * It needs a more complex synchronization mecanisms Of course, it can be associated with a dispatcher you can surely do things, but sharing a dispatcher between multiple threads is complex and easily error prone. NimGo on the other end (which is simply stackful coroutines with an event dispatcher very close to the one of std/ascyndispatch) : * Can fluently share data with closures, even GC memory (hopefully without leakage, but I cannot guarantee for now) * Is not very costly to create and run and to switch (under a thounsands, this is unnoticeable) * Is not limited to the number of pending I/O tasks. The advantages of NimGo compared to thread are close to the advantages of std/asyncdispatch over threads. They just don't answer the same problematics. And like std/asyncdispatch, you can have one dispatcher by thread, allowing to efficiently handles a very high number of connexions. For me NimGo should be compared instead with std/asyncdispatch with in fact only one big advantage : no function coloring (and everything that it implies). But at the cost of a higher memory usage. It proposes itself as an alternative for std/asyncdispatch by proposing a different paradigm (but has no vocation of being a concurrent).
