If scala advocate immutability why it adopted actor model with its mutable nature? [closed]

Question

I am new in scala and actor world.

This is what I've learned so far:

Scala is functional programming (not purely) and people advice not to use mutable state in scala.

But on another hand, there is akka framework which implements actor model. And during playing with akka I realized that the messages are immutable, BUT the state of the actors in MUTABLE. So, I need to specify inside of actors "var" variables and mutable collections. And, for me, to have a mutable state is not natural for scala.

So, does my understanding correct? Why do people adopted mutable actors model in immutable scala language?

Crocket

Sometimes you want to describe a mutable, concurrent model. Aside from FRP, there's nothing in the FP world that really helps with that in an intuitive way - and actors can model the local mutability (SRP) very well. – Barbe

This is a good technical question, it is not opinion-based: all queried aspects are precisely defined and answers can be derived logically. – Eyelet

Answer in short: 1) Scala is neither immutable nor purely functional. 2) Actors can be written without var or mutable collections, benefiting from referential transparency within an actor. 3) The Actor Model describes distributed systems, which necessarily implies non-determinism. Between actors, referential transparency does not exist, sending messages is necessarily a side-effect. 4) Please don’t mix a general purpose language, a programming paradigm, and a distributed systems model to create a false dichotomy. – Eyelet

Answer 1

This is an interesting point and indeed actors are quite different from the rest of Scala-like code.

You can think of actors as a replacement for threads with locks, semaphores and the rest. It is a more intuitive and performant model of concurrent programming since mutable state is always encapsulated in an actor that processes messages sequentially.

It provides a solid bedrock to build more functional abstractions. Akka team has produced akka-streams. Spark is using akka to communicate across nodes. Futures, another successful functional alternative to the problem is essentially a special case of streams: a stream of exactly one element and could be implemented using actors.

So, people use actors because some problems are solved more intuitively by having actors messaging each other than with operations on streams. Since the main argument against mutability is the complete mess it creates on concurrency, and actors solve exactly this, I guess it is okay to have this mutability. They are rather complex, but the proper solution to concurrency is actually this complex.

And just a note, streams are arguably the functional way to model any interaction of a program with its environment. E.g. for GUI development, you could provide all triggered events of controls as a stream, and folding the stream is essentially creating a way to manage the state of the program.

Tubman

"Spark is using akka to communicate across nodes". - I haven't heard about it before. Could you please point me where it is mentioned? – Crocket

Spark used Akka under the hood in the past, but has moved to using Netty/NIO since v1.6 apparently to avoid issues related to version inconsistency between the internal and external Akka Actors. – Sacci

Answer 2

Scala is a language that allows mixed models. It is trues that most examples use mutable state inside Actors but you can use Actors with immutable state using become :

class ListActor extends Actor {
  def receive = changeState(List.empty[String])

  def changeState(state: List[String]): Receive = {
    case Add(item) =>
      context.become(changeState(item :: state))
  }
}

Camion

become/unbecome or FSM are a nicer way to encapsulate mutation in akka but still these actors are mutable: If you send them a message, the responce will depend on their state. – Tubman

Any program that is not trivial needs state - Actors in Erlang also hold system state (as a recursion call to the actor, which is similar to what become does) – Camion

Answer 3

That's a good question with an interesting answer (IMHO): Scala is not functional. It's post-functional. Which means it unifies object oriented and functional programming into a single paradigm.

Within this framework, Scala favors immutability, but does not enforce it. The Actor model is one place where mutability makes sense, as all changes are local, the coordination of the concurrent behavior is done for you by the actor system.

Ynez

Care to explain the downvote? I included two links from Martin Odersky (inventor of Scala) supporting this view. – Ynez