The discussion around async await always focuses on asynchronous use-cases, but I see the biggest benefits when writing synchronous code. In JS, not having await in front of a statement means that nothing will interfere with your computation. This simplifies access to shared state without race conditions.

The other advantage is a rough classification in the type system. Not marking a function as async means that the author believes it can be run in a reasonable amount of time and is safe to run eg. on a UI main thread. In that sense, the propagation through the call hierarchy is a feature, not a bug.

I can see that maintaining multiple versions of a function is annoying for library authors, but on the other hand, functions like fs.readSync shouldn’t even exist. Other code could be running on this thread, so it's not acceptable to just freeze it arbitrarily.

▲

Yokohiii 2 hours ago | parent | next [-]

Maybe I am missing something. But the function coloring problem is basically the tension that async can dominate call hierarchies and the sync code in between looses it's beneficial properties to a degree. It's at least awkward to design a system that smoothly tries to blend sync that executes fast and async code that actually requires it.

Saying that fs.readSync shouldn't exist is really weird. Not all code written benefits from async nor even requires it. Running single threaded, sync programs is totally valid.

▲

IX-103 an hour ago | parent | next [-]

'readSync' does two different things - tells the OS we want to read some data and then waits for the data to be ready.

In a good API design, you should exposed functions that each do one thing and can easily be composed together. The 'readSync' function doesn't meet that requirement, so it's arguably not necessary - it would be better to expose two separate functions.

This was not a big issue when computers only had a single processor or if the OS relied on cooperative multi-threading to perform I/O. But these days the OS and disk can both run in parallel to your program so the requirement to block when you read is a design wart we shouldn't have to live with.

	▲	otabdeveloper4 20 minutes ago \| parent [-]
		> tells the OS we want to read some data and then waits for the data to be ready No, it tells the OS "schedule the current thread to wake up when the data read task is completed". Having to implement that with other OS primitives is a) complex and error-prone, and b) not atomic.

▲

tcfhgj an hour ago | parent | prev [-]

> Not all code written benefits from async nor even requires it. Running single threaded, sync programs is totally valid.

Maybe, but is it useful to have sync options?

You can still write single threaded programs

▲

gf000 3 hours ago | parent | prev [-]

> This simplifies access to shared state without race conditions

But in ordinary JS there just can't be a race condition, everything is single threaded.

▲

SkiFire13 3 hours ago | parent | next [-]

You can definitely have a race condition in JS. Being single-threaded means you don't have parallelism, but you still have concurrency, and that's enough to have race conditions. For example you might have some code that behaves differently depending on which promise resolves first.

▲

Kinrany 3 hours ago | parent | prev [-]

And it doesn't actually prevent concurrency.

▲

gf000 3 hours ago | parent [-]

Sure, but concurrent != parallel. You can't have data races with a single thread of execution - a while loop writing i=0 or i=1 on each iteration is not a data race.

Two async functions doing so is not a data race either.

▲

Rapzid 2 hours ago | parent | next [-]

You should really look up the definition of race condition; it has nothing to do with parallel processing. Parallel processing just makes it harder to deal with.

▲

gpderetta 3 hours ago | parent | prev [-]

Data race != Race condition

▲

gf000 3 hours ago | parent [-]

Data races are a specific race condition - they may be safe or cause tearing.

Serially, completely synchronously overwriting values is none of these categories though.

	▲	Maxatar 2 hours ago \| parent [-]
		You're mixing up quite a few somewhat related but different concepts: data races, race conditions, concurrency and parallelism. Concurrency is needed for race conditions, parallelism is needed for data races. Many single threaded runtimes including JS have concurrency, and hence the potential for race conditions, but don't have parallelism and hence no data races.