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...

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.

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.

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

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')

http://www.howtonode.org

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