Right, there is always an escape hatch, this is also true for haskell with unsafePerformIO - because of practicality.
That's a good thing :]
Re:Await in Rust
by heavenlyblue on Monday August 12, 2019 @10:21AM
(#20675632)
a) this function is clearly marked as sync
b) the question of why does it exist if the async version if available is beyond me
rom 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.
Top-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_o...
TIL - 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.
Re:Await in Rust
by michaelmior on Monday August 12, 2019 @11:30AM
(#20676318)
Agreed. 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.
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.