What is so hot about Scala in terms of concurrency?

[Gabriel Beres]

Hi,

I often hear that Scala is much better language to utilize multi core processors.
Are they referring to the Akka library, or the capability of doing functional programming? In my understanding, even if you write your code in functional way(without side effect and referentially transparent), it does not utilize multi core processors out of the box.

So what is the real deal here?

[Jayesh A Lalwani]

Gabriel Beres wrote:Hi,

? In my understanding, even if you write your code in functional way(without side effect and referentially transparent), it does not utilize multi core processors out of the box.

Yes, that's true. However, the first rule of writing highly scalable and concurrent applications is to write stateless code. Scala (or, rather, functional programming in general) forces you to write stateless code. It's not that Scala itself has capabilities that provide scalability. It's that when you write Scala code, you write code that can execute well in scalable platforms.

[Gabriel Beres]

What do you mean by stateless code?
Does that mean i have to completely give up on OO?

[Joe San]

Gabriel Beres wrote:What do you mean by stateless code?
Does that mean i have to completely give up on OO?

It is to avoid using mutable state in your classes. Normally, you have a state in your class through instance variable that is concurrently modifiable through multiple threads. Scala tends to avoid mutable state by declaring every variable as an immutable variable. This would mean that when your program runs across multiple cores, you need not worry about any side effects that may arise when using a mutable shared state.

[Jayesh A Lalwani]

Let's say you are building am application that is designed using MapReduce pattern. If you are not familiar with it, Map Reduce is a design pattern in which an expensive job gets executed by a master and multiple workers running concurrently. The master takes an expensive job and breaks it into chunks. The workers execute one chunk at a time, and return the results of each chunk. The master receives the result for each chunk and aggregates the results.

SO, let's assume that we already have some sort of framework that can execute worker jobs. A master just has to do the chunking and provide the chunks to the framework, and the framework will do the job of calling the workers. It will also deploy the workers on multiple machines, and the whole thing is transaprent to the master. So, the master looks like this

Let's say I'm building an application that needs to compute the average length of the word in a huge blob of text. I am implementing the master to divide up the text by words.. and each worker computes the length of each word

so, if you do this in Java, it will look something like this.

class AvgWordLengthJob {

   public int avgWordLen(String hugeText) {
       int[] wordlen = framework.executeWorkers(AvgWordLenCounter.class, hugeText.split());
       return average(wordLen);// compute average.
   }
}

class AvgWordLenCounter implements WorkerJob {

   int execute(String word) {
      return word.length;
   }
}

Here, when avgWordLen calls framework.executeWorkers, the framework internally distributes each word in the array to all the available workers, and calls execute on each worker. The workers will be called concurrently. Now, the problem here is the AvgWordLenCounter.execute has to be stateless. It shouldn;t have any side effects. It shouldn't modify any variable outside the function because if it did you will have to worry about thread safety/ synchronization of that variable.
In java, this is an easy mistake to make

class AvgWordLenCounter implements WorkerJob {

   int count;
   int execute(String word) {
      count =  word.length;
      return count;
   }
}

It's a silly mistake that makes the code thread unsafe and is very difficult to catch. It's a nightmare to find problems like these because these problems generally manifest as bugs that appear sporadically

Now, if you were in Scala world however, you can easily avoid this problem by making the worker job into a function. A function cannot have state

[Joe San]

Jayesh A Lalwani wrote:
Now, if you were in Scala world however, you can easily avoid this problem by making the worker job into a function. A function cannot have state

True but you could still have a mutable state in a function and that could be the starting point of your function not being scalable across CPU cores. One of the ideas behind functional programming is to completely avoid having a mutable state. You could write functional style code in any language, but with the help of higher order functions (i.e., passing functions as arguments and returning functions as a return type of a function), writing functional style code is much easier and Scala is very good at that.

[chris webster]

Gabriel Beres wrote:What do you mean by stateless code? Does that mean i have to completely give up on OO?

No, you don't have to give up on OO, because Scala is an OO language. But - as Joe and Jayesh have pointed out - Scala tries to minimise the use of mutable state, which is also good practice even in OO Java. So you can have classes and objects in Scala (and you can do lots of cool things with Scala case classes for example), but you try to avoid changing their state - which can cause side effects - except in controlled circumstances. One approach is to encapsulate mutability via state monads. Monads are a functional design pattern which can help to restrict side effects.

But you can start coding in Scala without knowing or worrying about monads etc, and just use "var" declarations for mutable objects. "var" defines a mutable variable so you know where the mutability is, but it's not encapsulated so there is a risk of mutating state causing problems in concurrent code, as in Java.

[Joe San]

The core language features of Scala extend beyond the capabilities of an OO language like Java. You have both the functional and object oriented features that you can use in Scala. From my limited experience with Scala thus far, I feel that it has a steep learning curve. It is definitely worth the effort to master it.

[Joe San]

You should see it to believe that writing non blocking, being immutable actually scales very well across CPU cores. Recently, for one of the project that I'm working on had lots of mutable state and blocking code and I was given the task to load test the application and try to find out ways by which the throughput of the entire application can be increased. The test was done on a 64 core machine and when I started, the application used only one thirds of the core and after a bit of re-factoring to use more of an evented approach and removing mutable state (to avoid any surprises), we found out that the application scaled perfectly and all the CPU cores were utilized and the throughput increased drastically. The feeling was just like driving a Boeing 747 with all 4 of its engines delivering power. I made it a point that any code that I write will never ever have any threads blocking and will always avoid having mutable state. Scala aids me in doing just that!