4 ms·

Concurrent programming is much more difficult and also come in numerous paradigms/flavors which unfortunately lacks an agreed-upon taxonomy and terminology, so

by klabb3 5y ago

Concurrent programming is much more difficult and also come in numerous paradigms/flavors which unfortunately lacks an agreed-upon taxonomy and terminology, so I'd forgive the author for making some confusing statements. Focusing on the "event loop" is a conceptual mistake imo, since it associates heavily to the (traditional) callback-oriented concurrency in JS. With callbacks, it is expected that shared state can be changed between registering and executing the callback. However, with async, this line is blurred enough to mess with the programmer's intuition (this is of course subjective, but I've seen enough to know that folks are confused). Async functions are (mostly) syntactic sugar for callbacks, and as such each await-point is where things can change - yet people don't expect it. When I help folks get up to speed on async, the first thing I call out is that the await points have this important semantic property. Any use of mutable state outside an async function is a ticking time bomb. The other thing that I disagree with is the "logical mutex" synchronization in js. Async iterators would be preferable in most real world situations, but they're not even mentioned. Async is a blessing if it's used sanely, but a curse if it's not. It doesn't magically make problems go away, but it can make your code more concise.

xg15 5y ago
I found it somewhat interesting psychologically how much of a paradigm shift async/await seems to have caused, even though it's really just syntactical sugar. It changed absolutely zero about JavaScript's processing model - but because it "looks" like traditional multithreaded code, people seemed to start thinking about it like that, suddenly asking about synchronization, locks, etc. You could have asked all those questions already during callback-hell times, but I don't remember reading any blogs about that stuff back then.
- klabb3 5y ago
  Agreed. People conflate concurrency with parallelism a lot, so I guess people see async, squint, "hey this is just like threads", and then start grabbing for locks. It appears to me that Javascript has painted itself into a corner where it needs to maintain 3 concurrency models for the forseeable future (callbacks, async, service workers), which is unfortunate for ecosystem interop. It's a shame because JS had this quite amazing property for such an old language that its concurrency model was simple, approachable and performant (within that single thread). Now that people build more general purpose stuff with it, those days are fading.

by klabb3 5y ago

xg15 5y ago

I found it somewhat interesting psychologically how much of a paradigm shift async/await seems to have caused, even though it's really just syntactical sugar. It changed absolutely zero about JavaScript's processing model - but because it "looks" like traditional multithreaded code, people seemed to start thinking about it like that, suddenly asking about synchronization, locks, etc. You could have asked all those questions already during callback-hell times, but I don't remember reading any blogs about that stuff back then.

klabb3 5y ago
Agreed. People conflate concurrency with parallelism a lot, so I guess people see async, squint, "hey this is just like threads", and then start grabbing for locks. It appears to me that Javascript has painted itself into a corner where it needs to maintain 3 concurrency models for the forseeable future (callbacks, async, service workers), which is unfortunate for ecosystem interop. It's a shame because JS had this quite amazing property for such an old language that its concurrency model was simple, approachable and performant (within that single thread). Now that people build more general purpose stuff with it, those days are fading.