> Without cancellation asyncdispatch could not handle timeouts. Chronos literally [didn't support cancellation until a few weeks ago](https://github.com/status-im/nim-chronos/pull/41#event-2463927708). Are you telling me you haven't been using it in production until just a few weeks ago?
> Without timeouts all network services written using asyncdispatch could not > be used in production This forum uses asyncdispatch, and has been doing so for the past 5+ years. If that's not production then I don't know what is. I am yet to see it get DoS'ed. **By the way, there are languages out there with async await implementations that do not support cancellation, one of them is used in an insurmountable number of production systems (https: //hacklang.org/)**. > [https://github.com/nim-lang/Nim/issues?q=is%3Aopen+is%3Aissue+label%3AAsync](https://github.com/nim-lang/Nim/issues?q=is%3Aopen+is%3Aissue+label%3AAsync), > in this list you can find issues which are 3 years old. That's a poor argument. You can find issues that are 7 years old in Nim's issue tracker: [https://github.com/nim-lang/Nim/issues?page=50&q=is%3Aopen+is%3Aissue&utf8=%E2%9C%93](https://github.com/nim-lang/Nim/issues?page=50&q=is%3Aopen+is%3Aissue&utf8=%E2%9C%93). By your logic we also shouldn't be using Nim. > Also do you remember that two years ago asyncdispatch do not have proper > exceptions support? No no. Nim _closure iterators_ did not have proper exception support and yes, I am very thankful that this was implemented by @yglukhov. I'm also very thankful of the features you have implemented in asyncdispatch and wish you continued doing so. Forking the implementation can be explained by Status' need to move fast, but forking and then telling everyone that they should stop using something that is a part of the Nim standard library is simply a detriment to our (already relatively small) community.
