-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Comments
async/await is js fibers (more or less) |
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. |
Here's information on the difference between generators and real coroutines: The same differences hold for async/await and real coroutines. |
Like fibjs did? Here is some discuss in ayo's issue.
The text was updated successfully, but these errors were encountered: