4 ms·

well I have never understood the "use erlang because CPUs are going multicore" argument. See if I write a program in C (which for some mysterious reason doesnt

well I have never understood the "use erlang because CPUs are going multicore" argument. See if I write a program in C (which for some mysterious reason doesnt use threads) and run it on a single core and it runs in 1 sec. If an equivalent erlang program runs in 10 seconds on 1 core, then I will need at least 10 cores before it beats C. That is assuming 100% of my application/algorithm is parallel. While erlang is a nice language, saying that it runs faster on multicores is just a lame excuse.

iamwil 19y ago
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.