I started this project with the following assumptions: * use libuv (or something similar) to avoid having to support code for every platform (this is really important, I don't want to test everything on >3 platforms even when making small changes) * have API as clean as possible.
I don't thing you and Araq would accept rewriting asyncdispatch to use libuv and dramatically changing the API of asyncdispatch/asyncnet. Future and Input/Output objects are incompatible with stdlib for good reasons - for example, using my abstractions, it's possible to: * efficiently implement `readLine` without using internals of socket object * do async calls without allocations in a more elegant way than `FutureVar` * write SSL/TLS support module without inlining it into module that supports sockets (!) To avoid the situation you described, I'm planning to write drop-in asyncdispatch/asyncnet replacement that will use reactor.nim loop. In the long run, I think the way to go is to define portable API for event loops (in a same way [Python does](https://docs.python.org/3/library/asyncio-eventloop.html#asyncio-event-loop)). This way, different async libraries could be bridged together.
