3 ms·

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 awai

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.

gf000 5mo ago
> 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.
- Kinrany 5mo ago
  And it doesn't actually prevent concurrency.
  - gf000 5mo ago
    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.
    - gpderetta 5mo ago
      Data race != Race condition
      - gf000 5mo ago
        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 5mo ago
        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.
        gf000 5mo ago
        Concurrency with a single thread of execution runs with complete mutual exclusion, so no "pure" single threaded concurrency is definitely race condition free. What we may argue over (and it becomes more of a what definition to use): IO/external event loop/signal handlers. These can cause race conditions even in a single threaded program, but one may argue (this is sort of where I am) that these are then not single threaded. The kernel IO operation is most definitely not running on the same thread of execution as JS. I think I have been fairly consistent in the definition of a data race as a type of race condition, where a specific shared memory is written to while other(s) read it with no synchronization mechanism. This can be safe (most notably OpenJDK's implementation is tear-free, no primitive or reference pointer may ever be observed as a value not explicitly set by a writer), or unsafe (c/c++/rust with unsafe, surprisingly go) where you have tearing and e.g. a pointer data race can cause the pointer to appear as a value that was never set by anyone, causing a segfault or worse.
        Kinrany 5mo ago
        You can implement your own event loop within a single thread
    - Rapzid 5mo ago
      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.
- SkiFire13 5mo ago
  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.
Yokohiii 5mo ago
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.
- tcfhgj 5mo ago
  > 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
  - Yokohiii 5mo ago
    I mean single threaded + sync. Sync options are useful. If everything is on the net probably less so. But if you have a couple of 1ms io ops that you want to get done asap, it's better to get them done asap.
    - tcfhgj 5mo ago
      > But if you have a couple of 1ms io ops that you want to get done asap, it's better to get them done asap. and async prevents this how?
      - Yokohiii 5mo ago
        my statement was in response to "fs.readSync shouldn't exist". that is how.
        tcfhgj 5mo ago
        if it didn't exist, the async version would still exist, which you could use to get it done asap

gf000 5mo ago

> 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.

Kinrany 5mo ago
And it doesn't actually prevent concurrency.
- gf000 5mo ago
  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.
  - gpderetta 5mo ago
    Data race != Race condition
    - gf000 5mo ago
      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 5mo ago
        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.
        gf000 5mo ago
        Concurrency with a single thread of execution runs with complete mutual exclusion, so no "pure" single threaded concurrency is definitely race condition free. What we may argue over (and it becomes more of a what definition to use): IO/external event loop/signal handlers. These can cause race conditions even in a single threaded program, but one may argue (this is sort of where I am) that these are then not single threaded. The kernel IO operation is most definitely not running on the same thread of execution as JS. I think I have been fairly consistent in the definition of a data race as a type of race condition, where a specific shared memory is written to while other(s) read it with no synchronization mechanism. This can be safe (most notably OpenJDK's implementation is tear-free, no primitive or reference pointer may ever be observed as a value not explicitly set by a writer), or unsafe (c/c++/rust with unsafe, surprisingly go) where you have tearing and e.g. a pointer data race can cause the pointer to appear as a value that was never set by anyone, causing a segfault or worse.
        Kinrany 5mo ago
        You can implement your own event loop within a single thread
  - Rapzid 5mo ago
    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.
SkiFire13 5mo ago
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.

Yokohiii 5mo ago

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.

tcfhgj 5mo ago
> 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
- Yokohiii 5mo ago
  I mean single threaded + sync. Sync options are useful. If everything is on the net probably less so. But if you have a couple of 1ms io ops that you want to get done asap, it's better to get them done asap.
  - tcfhgj 5mo ago
    > But if you have a couple of 1ms io ops that you want to get done asap, it's better to get them done asap. and async prevents this how?
    - Yokohiii 5mo ago
      my statement was in response to "fs.readSync shouldn't exist". that is how.
      - tcfhgj 5mo ago
        if it didn't exist, the async version would still exist, which you could use to get it done asap