After some time away from Nim I now notice that the async story for Nim seems to be based around async/await. Is this correct?
I have some bad experience working with async/await in big Typescript projects. async/await is much better that callbacks and promises, but still, the async/await has as a annoying tendency to infect other parts of the system. See this blog post for a better description of the problem; http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
After trying async/await I'm now a big fan of go-fibers, or N:M threading, with channels. I also see Java is investigating this path and already shows very interesting results, see: https://www.youtube.com/watch?v=vbGbXUjlRyQ.
Is this something Nim has/will consider? Nim coro (buggy but can be fixed?) + thread pool + io-lib that supports coroutines should make fibers possible?
I agree with @dom96. We have threading (even a luxury comfort version) and we have asynch. That's the basis for a modern language (which many do not have).
Fibers are a gadget. Nice to have but if that comes only in 2.0 that's good enough imo.
Excuse my somewhat harsh statement but right now the priority should be stability and 1.0. (and docs, more dev. tool support, ...)
Itch gone :)
No problem that you want to focus on 1.0, was just wondering about the async story for Nim since last I visited.
I'm glad to see that your itch is gone ;)
Let me explain my view a bit better (also for future reference for others).
A language is design + lots and lots of (hopefully good) work. Most people only see the work but not the design which is largely about making the right choices and decisions.
Threads are needed because they (and processes but those are much more expensive) are the mechanism to spread load over/use multiple cores or even processors.
Asynch on the other hand is needed to deal with bazillions of events (because unlike what many have learned in universities systems are basically reactors in an extremely event rich environment) and in particular in a way that doesn't waste cycles for waiting.
The classical AIO approach was something like libev and friends. But that's callback hell and a rich source of problems and errors. The await model is the ideal response to that; it's the "bridge" between reality (bazillions of events needing to be reacted to) and us humans thinking quite serially about our constructs.
The really, really decisive point was that Araq (possibly together with others) made the decision to chose the await mechanism. In fact, for myself that was a live or die condition for choosing Nim.
As for the work, lots and lots of work part we are not yet fully there. But the Nim team has achieved to create an amazingly good status quo. I'm really amazed how far we have come when I see not only the ease but also the reliability (in concept and to a large degree in code) of my code using the await mechanism.
The rest is gadgets (and lots of more work). eventlets for example, fibers, etc. are basically just variants or (small) extensions of what we already have. And that's also the reason why people like you who want those gadgets are best served by asking you for some more patience. Because the Nim team working on completing and getting rock solid what we have (towards 1.0) is also the very basis for the things you desire.
I agree, but I do think it is a bit funny that you view your gadget as a blocking feature and fibers as something much less important. Both are equally "gadget"-y, as none are really needed for async io. Callbacks/promises/futures and optional posix threads will get you there.
In my view, fibers solve async io much better than async/await. Fibers look and feels like a thread and do not infect codebase with async/await constructs all over the place. And both can be made equally performant.
Is fibers critical, no. I think 1.0 is much more critical. A possible future fiber implementation depend on a stable 1.0 as you put it.