3 ms·
I don't think the problem comes so much from async v. sync, it comes from the implementation language/framework. If you were to wait_for_event (or its equivale
by rileymat2 2y ago
I don't think the problem comes so much from async v. sync, it comes from the implementation language/framework.
If you were to wait_for_event (or its equivalent) in the node main thread you will stall the 1 thread handling requests.
This whole problem is not just async/sync, it is the environment you live in.
What we should be questioning is why high level languages in high level frameworks make the programmer even consider the distinction at all.
If I am handling an http request, the async nature of this is an optimization because threads (or worse, processes, I once easily dos'ed an apache system that created a new process for each request) are too expensive at scale.
It should not concern the programmer whether a thread is launched for each request or we are using cooperative multitasking (async). The programmer/application needs that information from that call before that one piece can move forward.
- vacuity 2y agoThe lower level async-as-state-machine (or coroutine or whatever) should be more standard, but that's an argument for another day. For now, you're right and the opaque threading model is basically what Go does. On the other hand, it's not suitable for Rust because in some ways Rust is lower level. C# went and did it the Rust way, which I personally appreciate but I understand fits into the problem you're describing.