core.async and 10,000 processes for animation - what is the actual benefit in this scenario?

Question

As we know - core.async uses CSP and is similar to goroutines from go-lang. Now for a scenario like select and alt this makes a lot of sense.

David Nolen has done an amazing demo here showing core.async in Clojure at work in animation in ClojureScript.

Yet I can replicate a similar functionality with a simple for loop. You can see a demo here.

function animationLoop() {
    for (var i =0;i<100;i++) {
        for (var j= 0; j<100;j++) {
            //decision to animate or hold off
            var decisionRange = randomInt(0,10);
            if (decisionRange < 1) {
                var cell = document.getElementById('cell-' + i + j);
                cell.innerHTML = randomInt(0,9);
                cell.setAttribute('class','group' + randomInt(0,5));
            }
        }
    }
}

My question is What is the actual benefit of core.async in the '10,000 processes animation scenario'?

Answer 1

The purpose of the demo is to demonstrate achieving concurrency in ClojureScript with core.async. The big wins are in writing all threads in a standard, sequential fashion, without needing to break them apart into callbacks or manage the interleaving by hand, and in the illusion of blocking on channels (including timeout channels; by blocking, a go yields control to other concurrent gos). Of course there is still no parallelism, but this is a completely orthogonal concept¹; using threads in GUI apps was a useful technique long before multicore CPUs became commonplace.

The resulting code makes things like refresh rate and rate of update generation immediately apparent. You could probably come close in clarity with for loops and setTimeout in this particular case, because all the update-generating gos do the same thing, but launching multiple gos to do completely different things would be equally straightforward.

---

¹ See for example Parallelism /= Concurrency by Simon Marlowe or Parallelism is not concurrency by Robert Harper for an extended discussion of this point.