why readFileSync and writeFileSync instead of having promises?

[mreinstein]

Looking at the roadmap document, I see the 2 exposed filesystem calls use the node similar syntax of
readFileSync and writeFileSync, but the fetch call returns a promise. I'm wondering why not just make readFile and writeFile be promise based and consistently return a promise event for any of these "will complete in the future" API calls?

[ry]

We can have those too, but sync file I/O is more often what is needed, and what we'll be implementing first.

[mreinstein]

ah ok, that seems reasonable if you think sync i/o is more common. Just wanted to make sure we weren't following a legacy node-ism unnecessarily. Thanks for the clarification.

[ZanderBrown]

When you consider await is there any difference as such?
(obs there is but hopefully you get the point)

[ry]

@ZanderBrown Yes- the sync methods can call directly into sync syscalls. The awaited async methods go through a thread pool and then polling for completion on the event loop - which ends up being slower in most cases.

[mreinstein]

^ ^ ^ ^ ^

This is probably the only lamentable thing I've encountered with async/await. It makes code appear synchronous syntactically but under the hood it's not.