2 ms·
> it is blocking your entire event loop for some executor In the browser, only. Which is where all this nonsense began. Browser didn't have threads (Win16) so
by dboreham 2y ago
> it is blocking your entire event loop for some executor
In the browser, only. Which is where all this nonsense began.
Browser didn't have threads (Win16) so they invented a crappy
cooperative scheme with callbacks, which became gussied up as "async" and now has a cult following. It was all a hack designed to make a terrible runtime environment usable. And now we have a priesthood telling us this is how to program, and if you disagree then you must be stupid.
You're correct that we should be using CSP (Erlang, Go, Occam, Actors).
- sweetjuly 2y agoIt's not completely to blame on the browsers. We had the concept of green threads [1] well before that, albeit for equally dubious reasons: OS threads were believed to be too slow, and so green threads were composed onto OS threads. It seems a better choice here would be to try and improve OS threads, but the speed at which various program languages and libraries develop well outstrips anything we could achieve with the kernel, and so maybe this was inevitable :) [1]: https://en.wikipedia.org/wiki/Green_thread https://en.wikipedia.org/wiki/Green_thread
- halostatue 2y agoNote that Erlang processes are essentially green threads within OS thread, but the Erlang process manager is preemptive (unlike most green thread managers). There is room for improvement in both directions.
- vacuity 2y agoOn the topic of improving OS threads, there are scheduler activations and similar mechanisms in some microkernels. Basically sending events for all hardware things and context switches, making user level threads as flexible as kernel threads. Unfortunately they haven't become mainstream.