
ES6 Generators Deliver Go Style Concurrency (2013) - stevekinney
http://swannodette.github.io/2013/08/24/es6-generators-and-csp
======
markwaldron
I read until Node.js 0.11 was mentioned and then scrolled up and realized it
was written in 2013. Please add to title!

~~~
stevekinney
Good point; I agree. Unfortunately, the window has passed for me to update the
title.

------
slaymaker1907
I think that even with generators, you don't quite get Go style concurrency
due to lack of concurrency for non-IO bound tasks. For a real world use case,
suppose you are compiling TypeScript. Without web workers or running in a
separate process, the compilation will block because it is CPU bound. You can
get around this with generators by explicitly putting in pause points through
yielding, but that is assuming that one can break up the task and that it
doesn't depend on some external blocking library.

~~~
mayank
You may possibly be conflating concurrency and parallelism. JS has concurrency
due to its event-based programming model, but not parallelism due to its
single-threaded nature.

The TypeScript compilation you mention likely has many concurrently running
tasks, just not in parallel (modulo the I/O thread pool as you mention).

------
emilsedgh
Can someone compare the concurrency method using async/await vs. generators?
What are the pro/cons of each?

It seems that with Async/Await, Generators are not as useful and are more
niche. Am I wrong?

~~~
treve
When you use Generators for this style of concurrency, generators are
comparable to async/await. The difference is that with async/await support,
you still have the option for your promises to resolve generators.

Basically by using generators for co-routines, you preclude yourself from some
use-cases that generators normally provide.

> Generators are not as useful and are more niche. Am I wrong?

I would say that generators are more general, and async/await actually more
specific to a single use-case.

------
codedokode
I think it is a bad idea to use generators to emulate threads. Because the
code becomes difficult to understand and it is easy to make a mistake (for
example forget to put a `yield` operator somewhere). I saw examples of such
code.

If you want threads, then make a syntax or API for them rather than implement
hacks nobody will want to deal with later.

~~~
aarpmcgee
I have the opposite opinion… I feel generators make async code dramatically
easier to understand.

~~~
codedokode
Easier than code written in Go for example? And what about handling exceptions
in asynchronous code with generators?

~~~
aarpmcgee
I find it especially easy to handle exceptions in asynchronous code with
generators. I'm interested to hear more about your perspective.

------
jiyinyiyong
[https://github.com/ubolonton/js-csp/](https://github.com/ubolonton/js-csp/) ?

------
piotrkaminski
Title needs a (2013) annotation.

