Given the scenario you've mentioned, sure, it doesn't make sense at to use something like erlang. This scenario is where a job takes longer the more you split

Given the scenario you've mentioned, sure, it doesn't make sense at to use something like erlang. This scenario is where a job takes longer the more you split it up. So it would be kinda like if I was a rolling a 10 meter (radius) snowball up myself and it takes me 1 hour, but if I split up the job amongst 9 other friends to get another 10m snowball, it would take each of us 1 hour instead of just 1/10 of a hour to roll up a tenth of that in volume (a 4.6m radius snowball) But if it doesn't take longer to do 1/10th of the job if I split the job up 10 times, then erlang would be a good fit. There are problems that cater to that, and those that don't. Pick the problems that do for this technique. These are the embarrassingly parallel problems that I mentioned earlier. So yes, just because you have multi-core, doesn't guarantee speedup. However, if the speed of a single CPU caps or slows in the future, and the number of cores increase on a chip, then us programmers have better have a good way to take advantage of that in our programs. Erlang and its actor model is one way.