Control-driven concurrency tends to be io-bound if being bound at all, and the major issue tends to be dealing with the complexity of the rules. I.e. if-that-happens then-start-that-thing which-tells-that-system and-then-continues-with-that-task which-notices-the-registered-plugins. These rules should not block for other concurrent but independent sessions. Scalability tends to be an issue here. A relevant scalability example for Erlang would be a telecom system where each machine-added make you able to handle X number of more subscribers.
Data-driven concurrency tends to be more about making use of the concurrency available in the current hardware generation to speed up very cpu-bound computations. Using more threads than cores available just mean more context-switches and less performance. These are problems that likely also want to make use of SIMD instructions.
Control-driven concurrency tends to be io-bound if being bound at all, and the major issue tends to be dealing with the complexity of the rules. I.e. if-that-happens then-start-that-thing which-tells-that-system and-then-continues-with-that-task which-notices-the-registered-plugins. These rules should not block for other concurrent but independent sessions. Scalability tends to be an issue here. A relevant scalability example for Erlang would be a telecom system where each machine-added make you able to handle X number of more subscribers.
Data-driven concurrency tends to be more about making use of the concurrency available in the current hardware generation to speed up very cpu-bound computations. Using more threads than cores available just mean more context-switches and less performance. These are problems that likely also want to make use of SIMD instructions.