> What if... Fibers and WaitFor were part of node core? > then you can deprecate almost half the functions at: http://nodejs.org/api/fs.html http://nodejs.org/

> What if... Fibers and WaitFor were part of node core? > then you can deprecate almost half the functions at: http://nodejs.org/api/fs.html http://nodejs.org/api/fs.html (clue: the Sync versions) Not quite. I use the Sync versions not to avoid callbacks, but to ensure that nothing else happens while I'm doing the operation. For example, take a look at the Database.reload function from this project (a NoSQL database written in Node): https://github.com/phusion/zangetsu/blob/master/lib/zangetsu/database.js#L103 https://github.com/phusion/zangetsu/blob/master/lib/zangetsu.... Reloading the database contents involves traversing multiple directories and reading multiple files. While reloading the database contents, I do not want the database to be modified. With asynchrony, the amount of different states that I have to be aware of rises so quickly that it's much, MUCH easier to use sync calls and tell the user "reloading is not concurrent, deal with it; at least it's correct". Wait.for does not solve this problem. It seems people believe that you can't run into concurrency problems or race conditions because Node is single threaded. This is false. I even had to write my own locks (https://github.com/phusion/zangetsu/blob/master/lib/zangetsu/database.js#L509 https://github.com/phusion/zangetsu/blob/master/lib/zangetsu...) because Node doesn't provide one.