Few cents from my side Seeing all that makes me kinda sad. Nim is pretty neat language and the ecosystem seems to be moving into the proper direction BUT situation like that especially just in sight of 1.0 is at least super concerning.
My experience with asyncdispatch is mostly positive BESIDES times where I've hit some corner cases / weird behaviour / undefined behaviour. Having something that is having a lot (let's be honest there...) corner cases, and kinda unexpected design decisions (.connect with UDP) is not super optimal I think, especially that the aim is 1.0. Not having cancellation is really hard block for me, I can't imagine having something running on production without being able to cancel the futures. It will basically screw up most of the error handling. I'm not saying that asyncdispatch is wrong, it's okish, but it requires A LOT of extra testing and stabilization. The community split between asyncdispatch and chronos (a hard fork of asyncdispatch) sounds very bad for me, especially that our community is rather small. In the same time, the existence of chronos proves that async is possible outside of stdlib which is great I think. Seeing and having that situation is definitely not helping nim with adoption... is there any sight how that can be solved/mitigated?
