Systems programmer here who's worked on both for more than a decade, I'll try my best to describe the tradeoffs I've learned and used, though my background is entirely C and C++.
First, "async event based" is common and necessary in threaded environments, so lets call the two competing solutions "thread based" and "event loop" based. Event loop is I think what you are really referring to, where a single event is processed from beginning to end, where flow is explicitly yielded back to a dispatcher for processing of another event.
Second, lets restrict this to single-core programming for a second. In any multicore environment you obviously need either multithreading or multiprocess design to get full utilization of your CPU. When "possible", as in your threads don't really need to be sharing data, I advise multiprocess over multithread but that's for simplicity and safety. But when thinking about each single core in that multicore solution...
Event loop programming is way faster (and actually easier to write) when your items of work (the things to be accomplished by the event) are all relatively the same length in terms of execution time AND have few IO operations. You don't need to worry about concurrency/races and there's no context switching. The moment either of those two conditions are violated, and threading starts becoming the better solution.
In a single threaded environment, IO means either blocking (shitty for perf) or making that IO a new event, and hand-writing state to store to continue processing the overall event later. Its a hand-optimized version of threading. You can do it and the payoffs are large, but as the complexity of each item of work grows, or the amount of IO you have to do grows, you will be writing more and more state structures and the efficiency of your coding (not the code execution) just keeps slowing down. In its worst case, you may have non-IO operations that are just really CPU intensive that make you save state as well to just avoid holding up everything else and creating large latencies. I remember having to write state off for a large signal processing routine that ground the CPU for seconds, gritting my teeth wishing we had threading for that particular project.
So threading becomes increasingly tantalizing as those items of work grow in complexity. When you have lots of IO in one item of work, or some items of work take way longer than others, you probably want to separate those off into threads. When you find items of work that are similar in computational size and without vast amounts of IO, put those into state machines / event-loops.
The two can even co-exist in the same project, with some threads hosting event loops, and others dedicated to special long running tasks.
Systems programmer here who's worked on both for more than a decade, I'll try my best to describe the tradeoffs I've learned and used, though my background is entirely C and C++.
First, "async event based" is common and necessary in threaded environments, so lets call the two competing solutions "thread based" and "event loop" based. Event loop is I think what you are really referring to, where a single event is processed from beginning to end, where flow is explicitly yielded back to a dispatcher for processing of another event.
Second, lets restrict this to single-core programming for a second. In any multicore environment you obviously need either multithreading or multiprocess design to get full utilization of your CPU. When "possible", as in your threads don't really need to be sharing data, I advise multiprocess over multithread but that's for simplicity and safety. But when thinking about each single core in that multicore solution...
Event loop programming is way faster (and actually easier to write) when your items of work (the things to be accomplished by the event) are all relatively the same length in terms of execution time AND have few IO operations. You don't need to worry about concurrency/races and there's no context switching. The moment either of those two conditions are violated, and threading starts becoming the better solution.
In a single threaded environment, IO means either blocking (shitty for perf) or making that IO a new event, and hand-writing state to store to continue processing the overall event later. Its a hand-optimized version of threading. You can do it and the payoffs are large, but as the complexity of each item of work grows, or the amount of IO you have to do grows, you will be writing more and more state structures and the efficiency of your coding (not the code execution) just keeps slowing down. In its worst case, you may have non-IO operations that are just really CPU intensive that make you save state as well to just avoid holding up everything else and creating large latencies. I remember having to write state off for a large signal processing routine that ground the CPU for seconds, gritting my teeth wishing we had threading for that particular project.
So threading becomes increasingly tantalizing as those items of work grow in complexity. When you have lots of IO in one item of work, or some items of work take way longer than others, you probably want to separate those off into threads. When you find items of work that are similar in computational size and without vast amounts of IO, put those into state machines / event-loops.
The two can even co-exist in the same project, with some threads hosting event loops, and others dedicated to special long running tasks.