With the above (specially the process and thread support), chronos itself is "mostly feature-complete", also when comparing it to asyncdispatch - we'll continue developing it of course, but the basic bits and pieces that we were hoping to get done are there. If you're still missing something relevant, open an issue.
We're tagging it as a new major version because your code might need a few adjustments to deal with the new exception effect requirements - these are described in the docs - we're also dropping support for Nim 1.2 / 1.4 - support starts at a recent 1.6 release.
What about ORC? Well, as part of making chronos memory-efficient, we've eliminated all allocation cycles in the core transformation - this makes chronos well suited for ORC in general. However, ORC is not yet stable enough for production, meaning we don't test it extensively beyond hoping the test suite will finish - YMMV - let us know if it works and / or provide fixes. If you actually need things to work, we recommend --mm:refc on Nim 2.0 (probably until 2.2 is released).
If you're using chronos, now is a good time to check out latest master as we'll be tagging 4.0 soon (or make sure to depend on 3.x specifically).
Congrats, but will that fix the nim-faststreams problem with chronos backend?
"chronos backend uses nested calls to waitFor which is not supported by chronos - it is not recommended to use it until this has been resolved"
Congrats, but will that fix the nim-faststreams problem with chronos backend?
No, this is an architectural problem with faststreams more than chronos (ie the faststream backend needs to be reengineered).
fwiw, chronos also has its own stream implementation which may or may not suite your needs: https://github.com/status-im/nim-chronos/tree/master/chronos/streams
I'd be interested in running some memory benchmarks on the HTTP server with ORC, especially some of the things I had issues with before like reading bodies. Now that the cycles are gone, it'll probably perform better and have fewer leak opportunities.
I think everyone who has seriously tried using ORC has run into the same leak issues, especially when it comes to asyncdispatch and to a lesser extent Chronos, but I'm not going back to refc so any improvements that makes async on ORC more usable is a win in my book.
I chose Go and a library in that ecosystem. I'm not here to shit on Nim, but the issues I had with ORC and slowness + leaks + everything else was too much.
The most promising thing I found was the nim-sys library's I/O, which uses CPS for coroutines. A simple benchmark HTTP server I wrote with that outperformed almost all other Nim HTTP servers, but the compilation time sucks because of the CPS macros, and there are limitations like no support for for loops inside CPS procs. If you want to fool around with a CPS webserver, you can try httpleast, which kind of cheats but shows how an HTTP server would be implemented with CPS.
A big part of what makes async/await in Nim slow is the fact that every Future needs to be allocated on the heap (as opposed to other langs like C# which has an optional stack future equivalent, and I think Rust's tokio has similar), and I think there are also inefficiencies with asyncdispatch's event loop and asyncnet. Those last two probably don't affect Chronos, especially after all the development it has gotten. If you look at httpbeast's code (it's easy to read the whole source, it's not super complicated), you'll notice that the fastest benchmarks don't allocate any Futures at all because they 1. don't use asyncnet, and 2. use a hack to allow nil instead of a Future return on handler procs. What people fail to mention is the fact that its event loop is optimized only for quick request-response, and it chugs when you send it request bodies, even fairly small ones if you send them in high volume. Chrono's HTTP server doesn't have this performance problem, although last I tried, it does leak under ORC. Chronos is just better designed, but few people use it because it's barely documented and everyone just sticks with default asyncdispatch because it's good enough for most people.
If I had to write an HTTP service in Nim right now, I'd probably go with Chronos because of its maturity. But ultimately, I can only return to Nim for web and network programming if it gets CPS in the compiler (or a VASTLY improved async/await runtime and ecosystem) and incremental compilation. Those are the two things that are holding it back for web right now in my eyes.
I know people are having success with Mummy and Gildenstern, but I need to use streams and therefore need async. Your needs will vary. Those are my two cents.