3 ms·

Really weird to throw in JS as the culprit, this is a long standing issue, the asynchronous nature of web work probably highlights it but dealing with asynchron

Really weird to throw in JS as the culprit, this is a long standing issue, the asynchronous nature of web work probably highlights it but dealing with asynchronous tasks is part and parcel of writing complex performant applications. Much may be hidden by modern dev environments, but you won't get far beyond the most simple apps before you need to start thinking about how to deal with it.

flohofwoe 3y ago
The point is that other solutions were able to use traditional threads or green threads (via stack switching) to solve the same problem without the compiler having to transform sequential code into a state machine under the hood (since pre-emptive threads can be suspended and continued at any time, and green threads at specific 'yield-points'). Javascript is limited by the single-threaded browser runtime, and the way that WebWorkers were bolted on later didn't help much because WebWorkers with message passing are too inflexible to implement even green-thread-style task switching. The state-machine code-transformation was indeed the only way out of this dilemma. Async/await is essentially high-level language syntax sugar and it shouldn't matter whether it is implemented via code-transformation, or with green-threads or real threads, or a combination of all those under the hood (but in reality it matters because there's a difference between 'code slices' being scheduled on the same thread or different threads when dealing with shared resources).
Pesthuf 3y ago
Especially weird because the feature actually originates from C# and was only copied by JS later. And in C#, you can absolutely combine it with Task.Run if you want it to run be concurrent. This feature made asynchronous operations so much better than all the patterns that came before it - and I think they goes for every language that ended up copying it.

flohofwoe 3y ago

The point is that other solutions were able to use traditional threads or green threads (via stack switching) to solve the same problem without the compiler having to transform sequential code into a state machine under the hood (since pre-emptive threads can be suspended and continued at any time, and green threads at specific 'yield-points'). Javascript is limited by the single-threaded browser runtime, and the way that WebWorkers were bolted on later didn't help much because WebWorkers with message passing are too inflexible to implement even green-thread-style task switching. The state-machine code-transformation was indeed the only way out of this dilemma. Async/await is essentially high-level language syntax sugar and it shouldn't matter whether it is implemented via code-transformation, or with green-threads or real threads, or a combination of all those under the hood (but in reality it matters because there's a difference between 'code slices' being scheduled on the same thread or different threads when dealing with shared resources).

Pesthuf 3y ago

Especially weird because the feature actually originates from C# and was only copied by JS later. And in C#, you can absolutely combine it with Task.Run if you want it to run be concurrent. This feature made asynchronous operations so much better than all the patterns that came before it - and I think they goes for every language that ended up copying it.