2 ms·
That bias is very much justified, I'd say. scala> (1 to 10).par.foreach(x=>print(x*x+",")) 4,9,1,49,36,16,81,25,64,100, Let me know how you'd para
by dxbydt 15y ago
That bias is very much justified, I'd say.
scala> (1 to 10).par.foreach(x=>print(x*x+","))
4,9,1,49,36,16,81,25,64,100,
Let me know how you'd parallelize the above in Java, how many lines of code it'll take, what syntactic constructs you'd end up using, what libraries you'd import, and finally your my mental model would be - in terms of locks and semaphores and so forth. The thing with scala is that concurrency - both data parallelism ( above example ) and task parallelism ( using actors in scala, a slightly longer example) are baked right into the language. A newbie in concurrency whose mental model doesn't incorporate thread pools or executor services or synchronous queues can progress leaps & bounds in scala vs java when it comes to concurrency.
- jbooth 15y agoIdeological bias is never justified. On to the justified bias: For that problem, I'd just do it serially, because it's only 10 numbers. Oh, it was an example for really big sets of numbers? Like really really big? Then I'd skip the .par.foreach and deal with java.util.concurrent directly, because it's worth my while if I have a serious problem worth optimizing. "A newbie in concurrency whose mental model doesn't incorporate thread pools or executor services or synchronous queues can progress leaps & bounds in scala vs java when it comes to concurrency." A newbie in concurrency needs to understand how many threads are in their threadpool, or else they should just do it serially. I'm not talking rocket science here, it's just a single integer argument.