ES6,ES7,ES8 and beyond. A Proposed Roadmap.

Brendan Eich brendan at mozilla.com
Sun Apr 21 10:09:45 PDT 2013


Domenic Denicola wrote:
> This looks lovely.
>
> The only thing I'd want to add: we need integers! And generally better numeric types. From speaking to developers on the ground, this is the biggest missing language feature they see (that isn't already addressed in ES6). I know Brendan has made some moves in this direction in SpiderMonkey, so let's just be sure it doesn't fall off the roadmap :).

Thanks, I bet Mark just forgot value objects are already on the ES7 agenda.

> Doing a quick poll of some IRC rooms, there's some call for shared-memory multithreading. I know this was a concern of the asm.js project, or more generally for the JS-as-a-compilation-target mission. I don't think this is a good idea, but just passing it along.

We're researching still and will not let arbitrary data races violate JS 
semantics (for one thing, this would hit all JITs that speculate 
assuming invariants obtained from JS's event-loop concurrency within the 
same realm, er, window -- it would break them all, AFAICT).

It may be that a Parallel JS "patient parent" model where 
non-overlapping slices of an array-buffer are handed off to workers, 
with results written back race-free, is enough for the interesting 
use-cases.

Wild shared-memory threading with fine-grained coordination? That is an 
anti-pattern in C/C++ due to the high cost of locking or equivalent 
lock-free techniques at scale. In related news, threads still suck.

> Finally, I know a lot of people, myself included, are excited about `await` sugar. That is, the plan would be to use generators + promises in ES6 with the awkwardness that entails; once we know what the prevailing patterns are we can eliminate that awkwardness with `await` in ES7. (I've made [a sketch][1] illustrating the idea, but of course the point of waiting is to find something that works, not the first thing I think up.) How this fits in with the concurrency strawman's more ambitious `!` operator is unclear though.

Not everyone is on board for making ! an infix operator via a restricted 
production.

As you say, we still want a clear cowpath to pave for 'await'. This 
means transpiler authors can help.

/be


More information about the es-discuss mailing list