Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring true coroutines(fiber) to deno in core code? #638

Closed
yuu2lee4 opened this issue Aug 30, 2018 · 3 comments
Closed

Bring true coroutines(fiber) to deno in core code? #638

yuu2lee4 opened this issue Aug 30, 2018 · 3 comments

Comments

@yuu2lee4
Copy link

Like fibjs did? Here is some discuss in ayo's issue.

@ry
Copy link
Member

ry commented Aug 30, 2018

async/await is js fibers (more or less)

@ry ry closed this as completed Aug 30, 2018
@zot
Copy link

zot commented May 14, 2020

Just looking to see if Deno supports fibers and I came upon this issue but I was surprised by the response.

I have to say that async/await really is not more or less fibers.

Async/await is actually like Haskell's IO values (and the IO monad) and not like coroutines because async/await makes a function return a promise, just like in Haskell when you want IO to happen, your function must return an IO value for IO to happen.

Async functions essentially force the entire chain of callers to be async all the way to very first function call -- call a single async function and you too must return a promise. Again, this "viral" behavior is like Haskell's IO values.

Mapping an async function over an array will get you an array of promises.

If you call an async function and then another function, you must await the first result or use then() in order for the effects to happen in sequence and if you don't, you have a floating promise.

Fibers do not have these... properties because they keep the complexity inside, it doesn't leak out and "taint" the return value with a promise. Fibers give you the option to pause and return a regular result, not a promise, async/await does not.

A fiber-based function can cause the current coroutine to wait until it gets a value and then just return the value itself, not a promise for it. If you map a fiber-based function over an array, you get back an array of the desired results, not an array of promises for results.

Call a fiber-based function that awaits a value and then call another function and their effects will happen in sequence, without the caller having to use await or then().

If you want/need to run with maximal asynchronicity, you still can use futures for that with fibers. or you can even still use promises -- fibers don't remove the functionality of promises, they just add the ability to keep the complexity internal to the function, rather than "infecting" callers with it if you want/need to do that. You can't do that with async/await or with promises.

@zot
Copy link

zot commented May 15, 2020

Here's information on the difference between generators and real coroutines:

yortus/asyncawait#51

The same differences hold for async/await and real coroutines.

hardfist pushed a commit to hardfist/deno that referenced this issue Aug 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants