[spion]

True. Though I suppose that writing an async generator runner that utilizes multiple workers (e.g. via webworkers in browser, via isolates in node - if they ever happen) is also possibly doable at some time in the future. Those generators wont have any access to the current scope, but that might be better[1]

Still, scheduling would continue to be cooperative via yield (just split amongst multiple threads). Go is clearly much further ahead in that regard :D

[1]: https://groups.google.com/forum/#!topic/golang-nuts/hZjvk-EP...

note: I'm curious, doesn't shared state from those closures let you shoot yourself in the foot in Go? You still have to be careful not to use anything not thread-safe that can potentially change...

[empthought]

Sure, but you always opt-in to using variables that are scoped outside of the current thread. You don't opt-in to the explicit control operators encouraged by the style where you don't use sequential statements -- they are required in order to program correctly. This is why I think the goto analogy is appropriate.