5 ms·

On an aside: what javascript really needed was async/await instead of generators. I have no clue why something as abstract as generators is being pushed. I mea

On an aside: what javascript really needed was async/await instead of generators. I have no clue why something as abstract as generators is being pushed. I mean the bane of javascript is the whole async programming with callbacks. Instead of solving the specific problem, this solves some problem which I don't see most apps having. Can someone in the know how care to explain?

thezilch 12y ago
generator = async yield = await Also, async/await themselves have a proposal accepted into ES7: https://github.com/lukehoban/ecmascript-asyncawait https://github.com/lukehoban/ecmascript-asyncawait
- mcav 12y ago
  Yeah, but only in the most trivial sense. Generators are a very, very poor substitute for proper yield support, just as they were when Python devs used them in Twisted.
- general_failure 12y ago
  From what I can tell, The generator pattern requires you to make all your functions generators. My understanding is that you can use yield only inside generators. For example, var data = await downloadSomething(); function *downloadSomething() { // check somethings return await http.get('foo.com', function (result) { yield result; }); } The above won't work since the callback to http.get is not a generator. You cannot make the callback a generator because it's not what a http.get expects. AFAIK, you have to instantiate a generator unlike a normal callback. Did c# actually require all the code to be changed into generator functions/new syntax to support await/async?
  - munificent 12y ago
    > My understanding is that you can use yield only inside generators. Async/await has identical limitations. You cannot call an async function from a synchronous one. Asynchrony poisons the entire callstack—everything that calls you must also become async. > Did c# actually require all the code to be changed into generator functions/new syntax to support await/async? I'm not sure if C# has this limitation, but if not, it's because C# has threads. If you call an async method from a sync one, it can just pause the sync one and run the async one on a different thread. JS can't do that.
    - saurik 12y ago
      This is only true if you are building the implementation of async/await as a compilation hack (maybe a "transpiler", as people now like to say) rather than as a feature of the virtual machine. You don't need "threads" to implement this, you just need the ability to work with multiple stacks and then have use the techniques from coroutines. (Some people call this "green threads", but that's not the kind of "threads" you would refer to when saying C# has threads.) I imagine the reason they avoided doing this was to not require browser vendors to make half their browser internals safe for usage in reasonable coroutines ;P. I can also see them having wanted to guarantee that the feature could be implemented using a transpiler rather than requiring it to be a native feature of the browser, and generators being explicitly marked at both the declaration and call sites (or async await with the limitations you mention) have that property by allowing a continuation passing transform to be applied to the generator's code. (Which could be applied to all code, of course, but not native browser code. edit: Well, you could so that as well, but it would violate other assumptions about how the code is supposed to work, and isn't something anyone has infrastructure to accomplish ;P.)
      - emn13 12y ago
        To condense what you're saying to its core: you can avoid the need to make callers async if you simply make everything async. In essence, that's the choice Go made. It's certainly simpler for the programmer. It probably makes optimization trickier, and it probably makes efficient parallelism harder (since real threads are completely abstracted away, the VM needs to understand when to start real threads, and when to use promises). For a language like javascript, it sounds like these tradeoffs are certainly worth it.
    - kevingadd 12y ago
      async/await is not based on generators. It's a compile-time transform that hoists parts of your function into independently scheduled asynchronous tasks & task callbacks. So it's essentially automatic CPS + promises. That's why functions are tagged as 'async' or not-async in C#; if they are 'async' they produce a promise instead of a value. On a related note, part of C#'s async/await infrastructure is a scheduling system so that callbacks can be configured to run on a specific thread - i.e. you can kick off async work on the UI thread and the callbacks will run there, instead of on the threadpool thread that completed the work.
  - interroboom 12y ago
    there are third party libraries (bluebird, co, Q, etc) that use generators to yield promises (or lightweight alternatives such as 'thunks'), and then a helper function that handles waiting for those promises/thunks to return and then resuming the generator. annoying that its not baked into ES6, but it means async code can be basically written like sync code (including typical error handling)
- tracker1 12y ago
  your comparison of generator/yield to async/await isn't exactly true... projects like co and koa take the generator/yeild combined with promises/thunks in order to satisfy similar requirements, but they are far from the same.
- findjashua 12y ago
  Please correct me if I'm wrong, but I think with generators, the caller has to keep calling next on it, which you don't have to with C# style async-await.
  - TazeTSchnitzel 12y ago
    In the C# style, someone is still calling next on it somewhere.
    - findjashua 12y ago
      So 'async' functions return a generator? If a library uses async-await, the library users have to call next on the generator? I assumed the language handled resuming the generator, so the users didn't have to.
dkarapetyan 12y ago
I think you're looking for this http://maxtaco.github.io/coffee-script/ http://maxtaco.github.io/coffee-script/.
afsina 12y ago
Dart is getting it in the next release. https://www.dartlang.org/articles/await-async/ https://www.dartlang.org/articles/await-async/
- stesch 12y ago
  In the meantime https://code.google.com/p/dart/issues/detail?id=13285 https://code.google.com/p/dart/issues/detail?id=13285 was moved up to Milestone-1.9 Forget about Dart. :-(
woah 12y ago
What's the bane of JS? Callbacks? That's probably because you were trained on languages without heavy use of asynchronous concepts. JS is my first language, and I have never had any sort of issue with callbacks. Most good JS coders never even have 'callback pyramids'. The pyramid is a symptom of A) bad modularity and encapsulation in your code and B) lack of clarity on which tasks depend on one another. The author ends up with a long 'laundry list' of things that happen to work in a certain order, and needs to ensure they happen in that exact order, using a pyramid.
- general_failure 12y ago
  I agree with your points but I was talking in the context of node.js. Having await/async will make node.js programming infinitely better. Lots of programming tasks in server side are really 'step' driven i.e doing a lot of things one by one. Of course, at this point someone will point me to 'async' and 'step' and 'q' modules but that's not the point.
  - woah 12y ago
    Good point. No reason not to have tools in the toolbox for when you need them. You might be interested in https://github.com/Raynos/continuable https://github.com/Raynos/continuable for dealing with async, it is an extremely simple library that allows you to build up async ops step by step. When you call the resulting function, it runs all the steps in the order you defined them.
kansface 12y ago
I disagree on both fronts. Languages should provide primitive constructs and allow libraries and frameworks to sort out the rest. It is nearly impossible to change a language after the fact, but libraries are free to come and go. The bane of JS really isn't async programming- it is branching async logic and this is exactly the problem that generators will solve. Moreover, libraries can choose to wrap them into callbacks so they will be backwards compatible. To get an idea of what this will look like, check out this library I wrote for Luvit (Nodejs for Lua) which relies on callbacks and coroutines to make async code look sync. https://github.com/kans/luvit-inlineCallbacks https://github.com/kans/luvit-inlineCallbacks
wldcordeiro 12y ago
Don't promises solve the callback issue?
rzimmerman 12y ago
I strongly agree. What would help most JS programmers (especially in node) would be to leverage the great asynchronous features in JavaScript and eliminate the nested function pyramid of doom. Callbacks and nested functions work great until you have conditionals or want to use try/catch blocks in a reasonable way. Promises are a viable solution but I've never really been a fan (it just feels weird). This was the rationale behind Kal (https://github.com/rzimmerman/kal/ https://github.com/rzimmerman/kal/), which effectively provides "await" (called "wait for") in ES5.

thezilch 12y ago

generator = async yield = await Also, async/await themselves have a proposal accepted into ES7: https://github.com/lukehoban/ecmascript-asyncawait https://github.com/lukehoban/ecmascript-asyncawait

mcav 12y ago
Yeah, but only in the most trivial sense. Generators are a very, very poor substitute for proper yield support, just as they were when Python devs used them in Twisted.
general_failure 12y ago
From what I can tell, The generator pattern requires you to make all your functions generators. My understanding is that you can use yield only inside generators. For example, var data = await downloadSomething(); function *downloadSomething() { // check somethings return await http.get('foo.com', function (result) { yield result; }); } The above won't work since the callback to http.get is not a generator. You cannot make the callback a generator because it's not what a http.get expects. AFAIK, you have to instantiate a generator unlike a normal callback. Did c# actually require all the code to be changed into generator functions/new syntax to support await/async?
- munificent 12y ago
  > My understanding is that you can use yield only inside generators. Async/await has identical limitations. You cannot call an async function from a synchronous one. Asynchrony poisons the entire callstack—everything that calls you must also become async. > Did c# actually require all the code to be changed into generator functions/new syntax to support await/async? I'm not sure if C# has this limitation, but if not, it's because C# has threads. If you call an async method from a sync one, it can just pause the sync one and run the async one on a different thread. JS can't do that.
  - saurik 12y ago
    This is only true if you are building the implementation of async/await as a compilation hack (maybe a "transpiler", as people now like to say) rather than as a feature of the virtual machine. You don't need "threads" to implement this, you just need the ability to work with multiple stacks and then have use the techniques from coroutines. (Some people call this "green threads", but that's not the kind of "threads" you would refer to when saying C# has threads.) I imagine the reason they avoided doing this was to not require browser vendors to make half their browser internals safe for usage in reasonable coroutines ;P. I can also see them having wanted to guarantee that the feature could be implemented using a transpiler rather than requiring it to be a native feature of the browser, and generators being explicitly marked at both the declaration and call sites (or async await with the limitations you mention) have that property by allowing a continuation passing transform to be applied to the generator's code. (Which could be applied to all code, of course, but not native browser code. edit: Well, you could so that as well, but it would violate other assumptions about how the code is supposed to work, and isn't something anyone has infrastructure to accomplish ;P.)
    - emn13 12y ago
      To condense what you're saying to its core: you can avoid the need to make callers async if you simply make everything async. In essence, that's the choice Go made. It's certainly simpler for the programmer. It probably makes optimization trickier, and it probably makes efficient parallelism harder (since real threads are completely abstracted away, the VM needs to understand when to start real threads, and when to use promises). For a language like javascript, it sounds like these tradeoffs are certainly worth it.
  - kevingadd 12y ago
    async/await is not based on generators. It's a compile-time transform that hoists parts of your function into independently scheduled asynchronous tasks & task callbacks. So it's essentially automatic CPS + promises. That's why functions are tagged as 'async' or not-async in C#; if they are 'async' they produce a promise instead of a value. On a related note, part of C#'s async/await infrastructure is a scheduling system so that callbacks can be configured to run on a specific thread - i.e. you can kick off async work on the UI thread and the callbacks will run there, instead of on the threadpool thread that completed the work.
- interroboom 12y ago
  there are third party libraries (bluebird, co, Q, etc) that use generators to yield promises (or lightweight alternatives such as 'thunks'), and then a helper function that handles waiting for those promises/thunks to return and then resuming the generator. annoying that its not baked into ES6, but it means async code can be basically written like sync code (including typical error handling)
tracker1 12y ago
your comparison of generator/yield to async/await isn't exactly true... projects like co and koa take the generator/yeild combined with promises/thunks in order to satisfy similar requirements, but they are far from the same.
findjashua 12y ago
Please correct me if I'm wrong, but I think with generators, the caller has to keep calling next on it, which you don't have to with C# style async-await.
- TazeTSchnitzel 12y ago
  In the C# style, someone is still calling next on it somewhere.
  - findjashua 12y ago
    So 'async' functions return a generator? If a library uses async-await, the library users have to call next on the generator? I assumed the language handled resuming the generator, so the users didn't have to.

dkarapetyan 12y ago

I think you're looking for this http://maxtaco.github.io/coffee-script/ http://maxtaco.github.io/coffee-script/.

afsina 12y ago

Dart is getting it in the next release. https://www.dartlang.org/articles/await-async/ https://www.dartlang.org/articles/await-async/

stesch 12y ago
In the meantime https://code.google.com/p/dart/issues/detail?id=13285 https://code.google.com/p/dart/issues/detail?id=13285 was moved up to Milestone-1.9 Forget about Dart. :-(

woah 12y ago

What's the bane of JS? Callbacks? That's probably because you were trained on languages without heavy use of asynchronous concepts. JS is my first language, and I have never had any sort of issue with callbacks. Most good JS coders never even have 'callback pyramids'. The pyramid is a symptom of A) bad modularity and encapsulation in your code and B) lack of clarity on which tasks depend on one another. The author ends up with a long 'laundry list' of things that happen to work in a certain order, and needs to ensure they happen in that exact order, using a pyramid.

general_failure 12y ago
I agree with your points but I was talking in the context of node.js. Having await/async will make node.js programming infinitely better. Lots of programming tasks in server side are really 'step' driven i.e doing a lot of things one by one. Of course, at this point someone will point me to 'async' and 'step' and 'q' modules but that's not the point.
- woah 12y ago
  Good point. No reason not to have tools in the toolbox for when you need them. You might be interested in https://github.com/Raynos/continuable https://github.com/Raynos/continuable for dealing with async, it is an extremely simple library that allows you to build up async ops step by step. When you call the resulting function, it runs all the steps in the order you defined them.

kansface 12y ago

I disagree on both fronts. Languages should provide primitive constructs and allow libraries and frameworks to sort out the rest. It is nearly impossible to change a language after the fact, but libraries are free to come and go. The bane of JS really isn't async programming- it is branching async logic and this is exactly the problem that generators will solve. Moreover, libraries can choose to wrap them into callbacks so they will be backwards compatible. To get an idea of what this will look like, check out this library I wrote for Luvit (Nodejs for Lua) which relies on callbacks and coroutines to make async code look sync. https://github.com/kans/luvit-inlineCallbacks https://github.com/kans/luvit-inlineCallbacks

wldcordeiro 12y ago

Don't promises solve the callback issue?

rzimmerman 12y ago

I strongly agree. What would help most JS programmers (especially in node) would be to leverage the great asynchronous features in JavaScript and eliminate the nested function pyramid of doom. Callbacks and nested functions work great until you have conditionals or want to use try/catch blocks in a reasonable way. Promises are a viable solution but I've never really been a fan (it just feels weird). This was the rationale behind Kal (https://github.com/rzimmerman/kal/ https://github.com/rzimmerman/kal/), which effectively provides "await" (called "wait for") in ES5.