3 ms·
> everything that doesn't use async/await is promised to never block or perform I/O I don't think that's true. See fs.readFileSync for example. You could say t
by michaelmior 7y ago
> everything that doesn't use async/await is promised to never block or perform I/O
I don't think that's true. See fs.readFileSync for example. You could say that's an exceptional case (which I think it is), but it means that there's no "promise" that functions without async/await don't perform I/O.
- inglor 7y agoRight, there is always an escape hatch, this is also true for haskell with unsafePerformIO - because of practicality. That's a good thing :]
- heavenlyblue 7y agoa) this function is clearly marked as sync b) the question of why does it exist if the async version if available is beyond me
- eropple 7y agorom a practical perspective, it's much easier to deal with `fs.readFileSync` in top-level code than to dive face-first into callbacks. (Remember, `fs.readFile` doesn't return a `Promise`.) If `fs` was promise-aware and top-level await existed, it would be a different conversation. As-is, for writing a one-off script, avoiding callback hell is pretty nice.
- michaelmior 7y agoAgreed. I've used it from time to time for writing simple scripts and it does make things much easier. You don't really have to worry about a CLI script blocking.
- amaranth 7y agoTop-level await is still a problem but a Promise version of the `fs` API has been available since Node v10. https://nodejs.org/api/fs.html#fs_fspromises_readfile_path_options https://nodejs.org/api/fs.html#fs_fspromises_readfile_path_o...
- eropple 7y agoTIL - never looked. (Most of our stuff is stuck on 8.x and I've got some work to do to upgrade us; never looked at the changes!) Thanks for the pointer.