It's great to get some infinite stream functionality in JS, but I don't see where this is helping in the realm of concurrency. Were there any particular use cases in mind when it was written, or was it primarily an exercise to push the use of generators?
Do you mean why couldn't you get the same concurrency using multi-threading? You could but that doesn't fit in all environments like node.js. Check out how koa.js can leverage similar concepts to reduce nested callbacks. Also beyond the concurrency the lazy loading aspect can have implications for functional programming techniques.
Comments
I wish at least the minimal set of these were in the language.
Does Wu.js conform to any of the fantasy-land specifications? https://github.com/fantasyland/fantasy-land
It's great to get some infinite stream functionality in JS, but I don't see where this is helping in the realm of concurrency. Were there any particular use cases in mind when it was written, or was it primarily an exercise to push the use of generators?
Do you mean why couldn't you get the same concurrency using multi-threading? You could but that doesn't fit in all environments like node.js. Check out how koa.js can leverage similar concepts to reduce nested callbacks. Also beyond the concurrency the lazy loading aspect can have implications for functional programming techniques.
It's about functional programming, not concurrency. We programmed Lisp back when it was just one core. Heck, back when memory was an actual 'core'.