4 ms·

ES6 Generators Deliver Go Style Concurrency (2013)

19 points by stevekinney 9y ago

piotrkaminski 9y ago
Title needs a (2013) annotation.
slaymaker1907 9y ago
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 9y ago
  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).
codedokode 9y ago
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 9y ago
  I have the opposite opinion… I feel generators make async code dramatically easier to understand.
  - codedokode 9y ago
    Easier than code written in Go for example? And what about handling exceptions in asynchronous code with generators?
    - aarpmcgee 9y ago
      I find it especially easy to handle exceptions in asynchronous code with generators. I'm interested to hear more about your perspective.
emilsedgh 9y ago
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 9y ago
  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.
markwaldron 9y ago
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 9y ago
  Good point; I agree. Unfortunately, the window has passed for me to update the title.
jiyinyiyong 9y ago
https://github.com/ubolonton/js-csp/ https://github.com/ubolonton/js-csp/ ?

19 points by stevekinney 9y ago

Title needs a (2013) annotation.

slaymaker1907 9y ago

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 9y ago
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).

codedokode 9y ago

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 9y ago
I have the opposite opinion… I feel generators make async code dramatically easier to understand.
- codedokode 9y ago
  Easier than code written in Go for example? And what about handling exceptions in asynchronous code with generators?
  - aarpmcgee 9y ago
    I find it especially easy to handle exceptions in asynchronous code with generators. I'm interested to hear more about your perspective.

emilsedgh 9y ago

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 9y ago
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.

markwaldron 9y ago

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 9y ago
Good point; I agree. Unfortunately, the window has passed for me to update the title.

jiyinyiyong 9y ago

https://github.com/ubolonton/js-csp/ https://github.com/ubolonton/js-csp/ ?