V8 developers start working on ES6 generators for JavaScript(code.google.com)
code.google.com
V8 developers start working on ES6 generators for JavaScript
http://code.google.com/p/v8/issues/detail?id=2355
32 comments
Note the opportunity here: all your promises code immediately turns into this: http://taskjs.org/
JS next seems almost as if they turned Javascript into Python. I am pleased.
I wish V8 already had generators back when node.js started. It would've been a true solution to callback hell. There's libraries like async to help with that, but it's not as good as something like tasks.js could be.
But on the other hand Twisted is not a panacea either, not that this is a perfect parallel or anything. But I agree, this is definitely a step in the right direction.
I wonder if it will be feasible to code in JS Next and have a compiler step somehow take care of backporting. Probably not.
I wonder if it will be feasible to code in JS Next and have a compiler step somehow take care of backporting. Probably not.
I am pleased too, but unfortunately it seems like they turned it into Python 3.
That is: not a stable, cross platform, version on the horizon yet --not even excluding IE--, and we're in for a long wait.
That is: not a stable, cross platform, version on the horizon yet --not even excluding IE--, and we're in for a long wait.
Not at all. We are seeing an extremely rapid adoption of ES6 features and the standard is going to be completely finalized this year (or early next year), meaning browsers don't really have a choice but to implement it.
That's already several years late. It was supposed to be ready around 2008 -- then it was cancelled, gone nowhere, and we had to wait another 5 years for ES6 which is still not here. I mean: "This year or early next year"? Add the sweet time the browser vendors will take, browser adoption etc, and it will be 2018 or 2020 when we can use it for mainstream sites.
Not to mention that the "browsers don't really have a choice but to implement it" does not hold at all. Safari, IE and Chrome can continue to ignore it or implement only little parts of it for the next 2-3 years.
Not to mention that the "browsers don't really have a choice but to implement it" does not hold at all. Safari, IE and Chrome can continue to ignore it or implement only little parts of it for the next 2-3 years.
Andy Wingo mentioned via twitter that he's working on it: https://twitter.com/andywingo/status/316644148532891648
Bloomberg is sponsoring Igalia (Andy) to implement ES6 generators in V8 :)
Ahaha, finally!
I have been waiting to use this feature on the web, well, since Mozilla implemented it, which must have been at least 5 years ago.
I have been waiting to use this feature on the web, well, since Mozilla implemented it, which must have been at least 5 years ago.
Why didn't ecma just use Mozilla's implementation?
Because the ES6 ECMA is made by a bloody time-wasting committee and the V8 team is also slow as hell to implement JS-level stuff (and let's not speak of IE and MS).
The spec is quite closely modelled after Mozilla's implementation, yes. Other engines just neglected to implement it.
> Other engines just neglected to implement it.
Why would they have? Seems like waiting for ecma approval and specification makes sense.
Why would they have? Seems like waiting for ecma approval and specification makes sense.
Sure, I didn't mean they did something wrong.
Although it is quite obviously a good idea :)
Although it is quite obviously a good idea :)
Ecma is a standards body, not an implementor. And standardizing things doesn't make them appear in other engines.
In the mean time you can use fibers with Node. I've been using them for StartHQ (http://starthq.com) via Common Node (https://github.com/olegp/common-node) and to be honest I don't see how I could have made it maintainable with promises, let alone no flow control library at all.
Agreed. Fibers are a great way to take simple synchronous-looking code and make it play well with the rest of node, without resorting to threads.
A bit offtopic, but: are all chromium & V8 team members Googlers? just wondering, chromium and V8 are both open source, but I've never head of any major contributors other than Google itself.
From what I gathered (ie. talking to mraleph) v8 is mostly just Google employees. I can't speak about Chromium.
The contributor situation is not vastly different for SpiderMonkey or JSC. I am usually the only contributor, besides 1-3 others that sometimes work on SpiderMonkey.
Edit: I think some ports are maintained from people outside Google. It's not really easy to tell, because most people have @chromium addresses.
Edit: I think some ports are maintained from people outside Google. It's not really easy to tell, because most people have @chromium addresses.
MIPS port is fully maintained by MIPS people. These days they even have commit rights.
You can see full list of people and organizations that contributed to V8 in the AUTHORS file.
You can see full list of people and organizations that contributed to V8 in the AUTHORS file.
[deleted](1)
Many people outside of Google have contributed small patches to both projects. A small set (maybe 20) of regular contributors have given commit access and an @chromium.org account. E.g. http://blog.chromium.org/2008/12/welcome-pawe-to-team.html . (A few of those people, including Paweł, were later hired by Google.) The vast majority of work is Googlers.
Anyone can contribute to V8. I've had a patch accepted and we are paying Igalia to add the ES6 generator support. The water's fine, jump in!
Just to hop on the train. This is true for SpiderMonkey as well. Just come visit us on IRC: irc://irc.mozilla.org/#jsapi. We are active around the clock, sometimes even at weekends. We discuss a lot of stuff directly on IRC, so you feel really involved.
See also: https://wiki.mozilla.org/JavaScript:New_to_SpiderMonkey
It seems that not, Andy Wingo, the guy who is implementing it, works for Igalia, a Spanish company/cooperative.
I've been really looking forward to this ever since I saw this post[1] on the possibilities that coroutines introduce for async programming.
This article in question was already discussed in some depth on HN[2].
Can't wait for an era of much more elegant async code!
[1] http://syzygy.st/javascript-coroutines/
[2] https://news.ycombinator.com/item?id=4912413
This article in question was already discussed in some depth on HN[2].
Can't wait for an era of much more elegant async code!
[1] http://syzygy.st/javascript-coroutines/
[2] https://news.ycombinator.com/item?id=4912413
The es wiki page linked in the bug doesn't say much about array/generator comprehensions, e.g.:
[for (x of a) for (y of b) x * y]
but those would be really nice as well.
A few months ago the ES committee decided to switch them from reading right-to-left (as in spidermonkey comprehensions, python, and haskell) to reading left-to-right (as in C#):
https://gist.github.com/dherman/b250d1fad15dbb5f77a5
[for (x of a) for (y of b) x * y]
but those would be really nice as well.
A few months ago the ES committee decided to switch them from reading right-to-left (as in spidermonkey comprehensions, python, and haskell) to reading left-to-right (as in C#):
https://gist.github.com/dherman/b250d1fad15dbb5f77a5
I'd love to use this for cooperative multitasking inside one thread (like in Python example using yield). Would be great for simple scripts for ai in games.
So who do we have to pay to get this turned on by default, instead of behind a flag?
PHP gets yield, now JS too?
You'd think it would be the other way round!
You'd think it would be the other way round!