Fiber is better than go's goroutine?

[Martin Nowak via Digitalmars-d]

On Tuesday, 28 October 2014 at 17:05:13 UTC, Andrei Alexandrescu
wrote:
> I'm not sure but as far as I understand this one issue forces 
> Go code to have a strong networking effect (must call into Go 
> code designed especially for cooperative threading). That 
> forces a lot of rewriting of existing code.
>
Yes these things only work with coroutine aware functions,
because they need to yield execution back to the scheduler when
some function blocks.
This is also true for our Fibers and the reason why vibe.d and
libasync implement their own Socket, File and Mutex primitives.

The await proposal mentioned in the other thread
(http://forum.dlang.org/post/izosaywbnlxnbzyhjbnu@forum.dlang.org)
solve this problem by using generic constructs (based on Promises
and Awaitable adapters).

It should be possible to define a notion of Resumable that is
compatible with Fibers, Stackless Resumable Functions and even
Callbacks (.then(doThis)).

So a scheduler would only need to know that it should resume a
Resumable once the associated Promise finishes. How the promise
is computed is irrelevant.