Node.js guys discussing async programming style(groups.google.com)
groups.google.com
Node.js guys discussing async programming style
http://groups.google.com/group/nodejs/browse_thread/thread/8dab9f0a5ad753d5
3 comments
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.
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.
Node has actually had quite a few blocking API's, I'm not sure for how long, but there has for quite a while been a fs.*Sync, they're just undocumented, because their usage isn't recommended.
[deleted](1)
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.
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.
For example, usinging XHR model:
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 = 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')node is amazing and the community is non-stop.
http://www.howtonode.org
http://wiki.github.com/ry/node/node-users
http://www.howtonode.org
http://wiki.github.com/ry/node/node-users
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...