Use yielding (await) in javascript today, with traceur(kyle.graehl.org)
kyle.graehl.org
Use yielding (await) in javascript today, with traceur
http://kyle.graehl.org/es6/javascript/development/2013/08/27/use-es6-yielding-today.html
3 comments
All calls aren't async though. You have to tell the compiler/interpreter that the thing you're calling is async by using the await keyword. That's the thing that I don't love about the C# await, JavaScript yield, etc. If I have to tell the compiler to yield then I still have to think about my program as asynchronous. And if I change a function to do an sync call, I still have to change it's own signature to be async, and anything that calls it, all the way up. So all you're really saving through these keywords is a bit of indentation. I don't really care about the indentation though; I use 2 spaces and just refactor when things get too far to the right.
Behind the scenes, no call happens instantly -- it only appears instant if the call is blocking at the source code level.
There is no guarantee that in the future the compiler/CPU will prevent other actions during a 'blocking' call. Blocking syntax is simply for the convenience of program structure.
Whether the call is blocking/synchronous or non-blocking/asynchronous is just a decision that was made at the language design level. Hence why node has both sync and async for file I/O.
Await/yield allows us to keep the concerns of the function in one code block rather than splitting them up -- regardless of whether the source author wrote the method as 'synchronous'.
Thinking about a program as async from the start avoids a ton of problems down the line.
There is no guarantee that in the future the compiler/CPU will prevent other actions during a 'blocking' call. Blocking syntax is simply for the convenience of program structure.
Whether the call is blocking/synchronous or non-blocking/asynchronous is just a decision that was made at the language design level. Hence why node has both sync and async for file I/O.
Await/yield allows us to keep the concerns of the function in one code block rather than splitting them up -- regardless of whether the source author wrote the method as 'synchronous'.
Thinking about a program as async from the start avoids a ton of problems down the line.
I personally love seeing the yield/await syntax before a function call. I don't like using gevent in Python because I feel like it's hiding important information from me. I much prefer actually being explicit about what the program is actually doing.
That's pretty awesome. I've been trying to keep up with ES6 stuff, but hadn't seen `await` yet.
I think that'll be especially handy in Node, where (in my experience) you're a lot more likely to deal with nested async operations.
I think that'll be especially handy in Node, where (in my experience) you're a lot more likely to deal with nested async operations.
I expect coffeescript will incorporate 'await' too.
jashkenas on yield and other ES6 features [1]:
Agreed. I think that we should start considering the new features
as soon as they begin to work in browsers, and on Node.
Once the realization hits that in the real world all programming calls are asynchronous, writing awkward code structure with callbacks/promises is unnecessary and just a crutch.
If I wasn't used Iced I would be using Traceur. ES6 features create code that is much more straightforward to understand, and quicker to write to boot.