3 ms·
> 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 i
by 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 agoThis 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.