4 ms·

I've written a lot of JS/TS over the last couple of years, and I've found that even though it may just be syntactic sugar, async/await is a major win in both ho

I've written a lot of JS/TS over the last couple of years, and I've found that even though it may just be syntactic sugar, async/await is a major win in both how easy it is to now write async code, and how readable the code is. Generators got us close to that, and it is a more generic feature. But over all the code I've written, I've only had one solid use case needing generators for something other than what's covered by async/await. Having a specific syntax that covers 95% of usages is very worth it in my opinion.

jkoudys 7y ago
Looking at the example I gave, how is `async function` any more clear than saying `co(function`? It covers the exact same use cases with equivalent clarity. They could've shipped the `Promise` object with a `coroutine` fn, like bluebird did, and had the same semantics without needing to reserve words and add syntax to the language. All it opens up is combining async and generators, which can be handy for iterating things like prefetched results, but that's a rare enough case not to need to be baked into the language. Separating the coroutine would let us work beyond just promises too. Wrap around old code using error-first callbacks, or new code using observables (yield to get the next, yield* to complete). I just wrote a coroutine to give quasi-concurrency to Google apps scripts, so it can queue up the routines running `fetch` methods and instead do them in one parallel-request-making `fetchAll`. It's a much better approach for the long-term of a language. Imho 90% of the junk we deal with in old languages is stuff for a convenient implementation at the time that we don't use anymore.
- kbsletten 7y ago
  In my opinion, the main reason to have `async` is because it doesn't require knowledge of generators. I've worked with developers who thought that `async`/`await` was too much trouble to learn and unnecessarily complicated. Promises allow us to act like nothing changed and functions return values. The trick, to me, is how do you meet that need without sacrificing these more powerful operations.
  - jkoudys 7y ago
    But it does require knowledge of generators. You're suspending a function during execution; that's what a generator is. We could've just named a global `async` that declares a coroutine FN on promises, and named `yield` as `await`, and the whole thing would look identical to now except for an extra paren and asterisk. You wouldn't need to understand their inner workings any more than you do with async/await now.
    - coldtea 7y ago
      >But it does require knowledge of generators. You're suspending a function during execution; that's what a generator is. That's like saying "Ordering from Amazon does require knowledge of driving a van. That's how the stuff comes to your home!".
      - tiglionabbit 7y ago
        No it's not. If the syntax is that similar, your metaphor makes no sense.
- coldtea 7y ago
  >Looking at the example I gave, how is `async function` any more clear than saying `co(function`? It covers the exact same use cases with equivalent clarity. It skips the generator part and extra wrapper. That's a simpler syntax (and thus more clarity) for what people do 99% of the time. Clarity is not necessarily "I can see the underlying mechanism". Generators hide their underlying implementation (in C++) too, after all.
  - gpderetta 7y ago
    > Generators hide their underlying implementation (in C++) too, after all. that has been contentious to say the least.

jkoudys 7y ago

Looking at the example I gave, how is `async function` any more clear than saying `co(function`? It covers the exact same use cases with equivalent clarity. They could've shipped the `Promise` object with a `coroutine` fn, like bluebird did, and had the same semantics without needing to reserve words and add syntax to the language. All it opens up is combining async and generators, which can be handy for iterating things like prefetched results, but that's a rare enough case not to need to be baked into the language. Separating the coroutine would let us work beyond just promises too. Wrap around old code using error-first callbacks, or new code using observables (yield to get the next, yield* to complete). I just wrote a coroutine to give quasi-concurrency to Google apps scripts, so it can queue up the routines running `fetch` methods and instead do them in one parallel-request-making `fetchAll`. It's a much better approach for the long-term of a language. Imho 90% of the junk we deal with in old languages is stuff for a convenient implementation at the time that we don't use anymore.

kbsletten 7y ago
In my opinion, the main reason to have `async` is because it doesn't require knowledge of generators. I've worked with developers who thought that `async`/`await` was too much trouble to learn and unnecessarily complicated. Promises allow us to act like nothing changed and functions return values. The trick, to me, is how do you meet that need without sacrificing these more powerful operations.
- jkoudys 7y ago
  But it does require knowledge of generators. You're suspending a function during execution; that's what a generator is. We could've just named a global `async` that declares a coroutine FN on promises, and named `yield` as `await`, and the whole thing would look identical to now except for an extra paren and asterisk. You wouldn't need to understand their inner workings any more than you do with async/await now.
  - coldtea 7y ago
    >But it does require knowledge of generators. You're suspending a function during execution; that's what a generator is. That's like saying "Ordering from Amazon does require knowledge of driving a van. That's how the stuff comes to your home!".
    - tiglionabbit 7y ago
      No it's not. If the syntax is that similar, your metaphor makes no sense.
coldtea 7y ago
>Looking at the example I gave, how is `async function` any more clear than saying `co(function`? It covers the exact same use cases with equivalent clarity. It skips the generator part and extra wrapper. That's a simpler syntax (and thus more clarity) for what people do 99% of the time. Clarity is not necessarily "I can see the underlying mechanism". Generators hide their underlying implementation (in C++) too, after all.
- gpderetta 7y ago
  > Generators hide their underlying implementation (in C++) too, after all. that has been contentious to say the least.