Async iterators. What do you think?

[Santiago Basulto]

Hello guys. I've been doning some experiments with Async iterators. You can find more details in the repo I created[1] but I'll explain my rationale behind it quickly: I'm a heavy python user and I love iterators. They provide a nice and clean interface. When I started to get into node.js I noticed the "lack" (or the lower use, to be precise) of them and started doing some research. The problem I found was that, for async architectures, blocking/regular iterators doesn't look like a good fit. Well, that's just something I think, maybe I'm wrong. Please share your thoughts.

[1] https://github.com/santiagobasulto/async-iterators

[Alexey Petrushin]

I'm not sure that your iterator is async - there's no way to stop and continue on demand. You may also try something like this

    collection.asyncEach(function(err, chunk, next){

      if(err) throw err

      console.log(chunk)

      next()

    })

[Santiago Basulto]

What code? In the `prime-example` code I'm certainly doing stuff wrong. I'm starting with concurrency on node.js and I'm still learning. The code on the `http-example` is async.

[Rebecca Turner]

Personally, for most scenarios that call for blocking iterators in other languages, I'd use streams in object mode.

On July 22, 2014 at 1:17:57 PM, Santiago Basulto (santiago...@gmail.com) wrote:

Hello guys. I've been doning some experiments with Async iterators. You can find more details in the repo I created[1] but I'll explain my rationale behind it quickly: I'm a heavy python user and I love iterators. They provide a nice and clean interface. When I started to get into node.js I noticed the "lack" (or the lower use, to be precise) of them and started doing some research. The problem I found was that, for async architectures, blocking/regular iterators doesn't look like a good fit. Well, that's just something I think, maybe I'm wrong. Please share your thoughts.

[1] https://github.com/santiagobasulto/async-iterators

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/600ce235-7ab7-487f-8c49-af8c1209c588%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mog...@syntheticsemantics.com]

Hi Santiago,

I recently did some benchmarking of synchronous work with the Cluster module (http://nodejs.org/api/cluster.html) versus conventional asynchronous programming and found Cluster processes can have lower latency and higher throughput than asynchronous methods: http://synsem.com/SyncNotAsync/

The latency of synchronous operations is masked by having enough Cluster processes so some are always free to immediately service a new request (as few as 2-3 servers may be needed).  An additional benefit of the Cluster execution model is unavoidable computation in the event loop executes on multiple cores gaining a mechanical advantage over sequential execution in a single event loop.  The penalty for synchronous or sloppy programming is very low compared to a single event loop.

The Cluster module is experimental but not very invasive so if things change there is not much effort to loose or effort required to keep up.  In addition to callbacks and promises, Cluster can be a very useful tool.

          -J

[Bruno Jouhier]

Hi Santiago,

This is very similar to the starting point of my ez-streams library. The difference is that I'm passing an error parameter to the callback and that I called the method read rather than next.

Next step is to treat it as a monad and decorate it with an array-like API (but async) and other goodies.

See https://github.com/Sage/ez-streams for details.

Bruno