Modern processors are much faster than the outlying memory and persistent storage devices. They and compilers in combination are relatively good at optimizing for predictable patterns of using sequential blocks of the outlying memory. Context switches between tasks are expensive, because the state of the processor must be (at least partially) serialized and stored as well as the loss of the implicit context of the caches.<p>Thus it makes /far/ more sense to have a number of threads (dependent on the hardware capacity and how readily the problem can be divided to independent or very loosely coupled tasks) which poll message queues than it does to have a completely independent thread for every event.<p>Languages based around message passing are thus the obvious choice for this type of programming.
Threads vs. events is a false dichotomy to me. Currently writing an event-driven finite state machine dispatcher that fires up threaded processes to perform long-running tasks that do not modify state. The FSM brings order and structure to chaotic event interactions, while threading enables full utilization of CPU cores. All the better to drain your battery, lol. Seriously though, I made this choice to balance reliability with responsivenes.<p>Choose the right tool for the job.
here's a link to a related discussion on HN entitled Why Threads are a Bad Idea (for most purposes) (1995)"<p><a href="https://news.ycombinator.com/item?id=14547063" rel="nofollow">https://news.ycombinator.com/item?id=14547063</a>