4 ms·

If the author likes to see explicit `async` label on functions, he misses the pleasure of having `async` on every function. a = x + z; b = y + x; That

If the author likes to see explicit `async` label on functions, he misses the pleasure of having `async` on every function. a = x + z; b = y + x; That's concurrency laying on the table - refactor your code to run those two lines in parallel.

TheCoelacanth 6y ago
That's an entirely different kind of concurrency. Those statements are just going to run on the CPU. It's only faster to do them in parallel if you have an extra CPU core lying around and if the overhead of splitting it across CPUs doesn't outweigh the time saving of doing both at once (it almost never does for such a small piece of work). With async functions, the CPU isn't actually doing anything. It's just waiting for something to happen, like a network response from another machine. It's almost always faster to do them in parallel if possible.
- avodonosov 6y ago
  > for such a small piece of work Don't take the example too literally, some function calls can be here. Running computations in parallel is often valuable. Or run computations in parallel with waiting for external resource - why does not the code in the article compute something while waiting for a, b and c? Anyways, if async functions are so good, why not have all functions async? The article says this a kind of "documentation" that tells you what functions can wait for some external data and what functions are "pure computation". If it was so, it would be OK. Such a documentation could be computed automatically based on the called function implementations and developer is hinted: "these two functions you call are both async, consider waiting for both in parallel". In reality, the async / await implementations prevent the non-async functions from becoming async without the calning code change. This restriction is just a limitation of how async / await is implemented, not something useful. As other commenter says, the article "embraces a defect introduced for BC reasons as if it's sound engineering. It really isn't." When my code is called by a 3rd party library, I can not change my code to async. That's the most unpleasant property of today's async / await. What yesterday was quick computation tomorrow can become a network call. For example, I may want the bodies of rarely used functions to only load when called first time (https://github.com/avodonosov/pocl https://github.com/avodonosov/pocl). The article suggests we have to decide upfront, at the top-level of the application / call stack, which parts can be implemented with as waiting blocks and which should never wait for anything external. This is not practical. > It's almost always faster to do them in parallel if possible. Yes, if possible. And it is determined, in particular, by dependencies between the operations. If the first call is writing to DB and the second call is a query that reads the same DB cell, they can't be parallelized. The same is with in memory computations - if next steps do not depend on previous steps they can be parallelized. Hopefully, compilers of the future will be able to automatically parallelize computations.
  - TheCoelacanth 6y ago
    > Anyways, if async functions are so good, why not have all functions async? They aren't. They're only good when the primary thing that the function is doing is waiting. > When my code is called by a 3rd party library, I can not change my code to async. That's the most unpleasant property of today's async / await. What yesterday was quick computation tomorrow can become a network call. You can still do that. Network calls don't have to be async. Blocking network calls still exist, just as they did before async was created. > Hopefully, compilers of the future will be able to automatically parallelize computations. Ah, yes, the famous sufficiently smart computer that can determine if two operations happening on the other side of the network depend on each other or not. Personally, I'm not holding my breath.
    - avodonosov 6y ago
      > Blocking network calls still exist, Browsers have already deprecated sync XMLHttpRequest.
      - TheCoelacanth 6y ago
        This article was focused primarily on Rust, which does not have that problem. Needing to add async to a function is problematic in JS, but it's far less problematic than the alternative which is completely rewriting your function to be event-driven. Blocking network calls aren't a possibility in JS due to the choice to make the entire runtime single-threaded.
donkarma 6y ago
Would your CPU not do this automatically?

TheCoelacanth 6y ago

That's an entirely different kind of concurrency. Those statements are just going to run on the CPU. It's only faster to do them in parallel if you have an extra CPU core lying around and if the overhead of splitting it across CPUs doesn't outweigh the time saving of doing both at once (it almost never does for such a small piece of work). With async functions, the CPU isn't actually doing anything. It's just waiting for something to happen, like a network response from another machine. It's almost always faster to do them in parallel if possible.

avodonosov 6y ago
> for such a small piece of work Don't take the example too literally, some function calls can be here. Running computations in parallel is often valuable. Or run computations in parallel with waiting for external resource - why does not the code in the article compute something while waiting for a, b and c? Anyways, if async functions are so good, why not have all functions async? The article says this a kind of "documentation" that tells you what functions can wait for some external data and what functions are "pure computation". If it was so, it would be OK. Such a documentation could be computed automatically based on the called function implementations and developer is hinted: "these two functions you call are both async, consider waiting for both in parallel". In reality, the async / await implementations prevent the non-async functions from becoming async without the calning code change. This restriction is just a limitation of how async / await is implemented, not something useful. As other commenter says, the article "embraces a defect introduced for BC reasons as if it's sound engineering. It really isn't." When my code is called by a 3rd party library, I can not change my code to async. That's the most unpleasant property of today's async / await. What yesterday was quick computation tomorrow can become a network call. For example, I may want the bodies of rarely used functions to only load when called first time (https://github.com/avodonosov/pocl https://github.com/avodonosov/pocl). The article suggests we have to decide upfront, at the top-level of the application / call stack, which parts can be implemented with as waiting blocks and which should never wait for anything external. This is not practical. > It's almost always faster to do them in parallel if possible. Yes, if possible. And it is determined, in particular, by dependencies between the operations. If the first call is writing to DB and the second call is a query that reads the same DB cell, they can't be parallelized. The same is with in memory computations - if next steps do not depend on previous steps they can be parallelized. Hopefully, compilers of the future will be able to automatically parallelize computations.
- TheCoelacanth 6y ago
  > Anyways, if async functions are so good, why not have all functions async? They aren't. They're only good when the primary thing that the function is doing is waiting. > When my code is called by a 3rd party library, I can not change my code to async. That's the most unpleasant property of today's async / await. What yesterday was quick computation tomorrow can become a network call. You can still do that. Network calls don't have to be async. Blocking network calls still exist, just as they did before async was created. > Hopefully, compilers of the future will be able to automatically parallelize computations. Ah, yes, the famous sufficiently smart computer that can determine if two operations happening on the other side of the network depend on each other or not. Personally, I'm not holding my breath.
  - avodonosov 6y ago
    > Blocking network calls still exist, Browsers have already deprecated sync XMLHttpRequest.
    - TheCoelacanth 6y ago
      This article was focused primarily on Rust, which does not have that problem. Needing to add async to a function is problematic in JS, but it's far less problematic than the alternative which is completely rewriting your function to be event-driven. Blocking network calls aren't a possibility in JS due to the choice to make the entire runtime single-threaded.

donkarma 6y ago

Would your CPU not do this automatically?