

Node.js guys discussing async programming style - jokull
http://groups.google.com/group/nodejs/browse_thread/thread/8dab9f0a5ad753d5

======
xal
I think this is the point where node is getting a bit silly.

It's a wonderful tool with a clear purpose: simple high performance network
servers that usually tie together a bunch of different servers behind them. If
they are trying to turn Node into something else they are going to hit a brick
wall.

The proposal acknowledges that the current JS/V8 cannot really deliver on the
original promise that all IO should be async. This is mainly because of
awkward syntax in JS. The awkward syntax comes from the lack of native
futures.

There are two ways forward: Change JS and add native futures to Node or supply
blocking IO libraries to the users and move the complexity of async vs
blocking to the programmers. If that's the path they chose, what will
distinguish Node from high performance network libraries in other languages,
such as EventMachine and Twisted? Node has it's reputation for speed precisely
because it doesn't offer any blocking operations.

Personally I think the focus should be on crafting transparent futures into
the JS language that Node uses. Take the IO language as an example:
[http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.h...](http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.html#Concurrency-
Futures)

~~~
mhansen
_The proposal acknowledges that the current JS/V8 cannot really deliver on the
original promise that all IO should be async. This is mainly because of
awkward syntax in JS. The awkward syntax comes from the lack of native
futures._

Where does the proposal acknowledge this? This discussion is about different
_styles_ of evented async programming, e.g. Promises vs pure function
callbacks. What awkward syntax do you mean?

 _If that's the path they chose, what will distinguish Node from high
performance network libraries in other languages, such as EventMachine and
Twisted?_

The main thing distinguishing Node from these frameworks is JavaScript's easy
anonymous functions for easy asynchronous callbacks.

 _Node has it's reputation for speed precisely because it doesn't offer any
blocking operations._

Node does offer blocking operations e.g. on the file system. I use them once
when the program starts up to read configuration data. It's not going to cause
problems unless you're doing blocking IO on every connection.

Node has a reputation for being able to scale to thousands of connections due
to its evented nature - not a reputation for speed.

------
Kilimanjaro
Personally, I love the way xmlhttprequest handles asynchrony.

Every process/function that deals with i/o,db,etc should provide at least two
events onReady and onError (drop the 'callback' and 'errback' aberrations) and
leave JS as pure as it is right now.

Other events may be used like onProgress, onLoad, etc.

~~~
Kilimanjaro
For example, usinging XHR model:

    
    
      file = new File.Reader()
      file.onReady    = printfile
      file.onError    = showerror
      file.onProgress = showprogress
      file.read('myfile.txt')
    

Not restricted to callback and errback only, more events may be available
according to the process being executed, keeping JS as natural as possible.

Hacks can be added on top to handle parallel or chainable process.

One last thing, make the process asynchronous by default and set a property to
false to make it synchronous, no need to force a last parameter to a function.

    
    
      file.async = false
      file.read('myfile.txt')

------
JimBastard
node is amazing and the community is non-stop.

<http://www.howtonode.org>

<http://wiki.github.com/ry/node/node-users>

