CODEWITHSUNDEEP
scalaakkascalabilitydistributedactor
Casper Thule Hansen
Casper Thule Hansen

Reputation: 1550

Untyped vs TypedActors - why use untyped?

I am trying to understand why one would use untyped actors over typed actors. I have read several posts on this, some of them below: What is the difference between Typed and UnTyped Actors in Akka? When to use what? http://letitcrash.com/post/19074284309/when-to-use-typedactors

I am interested in understanding why untyped actors are better in the context of:

I am aware, that untyped actors are better in the context of FSM because of the become/unbecome functionality.

I can see the possibilities of untyped in a load balancer, as it does not have to be aware of the contents of the messages, but just forward them to other actors. However this could be implemented in a typedactor as well.

Can someone come up with a few use case in the areas mentioned above, where untyped actors are "better"?

Upvotes: 3

Views: 665

Answers (3)

ayvango
ayvango

Reputation: 5977

There is a generic disadvantage for type actors: they are hard to extend. When you use normal traits you can easily combine them to build object that implements both interfaces

trait One {
  def callOne(arg : String)
}
trait Two {
  def callTwo(arg : Double)
}
trait Both extends One with Two

The Both trait supports two calls combined from two traits.

If you usage actor approach that process messages instead of making direct calls you is still capable with extending interfaces refusing type safety as price.

trait One {
  val receiveOne : PartialFunction[String,Unit] = {
    case msg : String => ()
  } 
}
trait Two {
  val receiveTwo : PartialFunction[Double, Unit] = {
    case msg : Double => ()
  }
}
trait Both extends One with Two {
  val receive : PartialFunction[Any, Unit] = receiveOne orElse receiveTwo
}

The receive value in Both trait combines two partial functions. The first accepts only Strings, the second - only Doubles. They have single common supertype: Any. So extended version should use Any as argument and becomes effectively untyped. The flaw is in scala type system that supports type multiplication using with keyword, but does not support union types. You could not define Double or String.

Typed actors lose ability for easy extension. Actors shifts type checks to contravariant position and extending it requires union types. You can see how they works in ceylon programming language.

It is not that untyped and typed actors have different sphere of application. All questioned functionality may be expressed in terms of both. The choice is more about methodology and convenience.

Typing allows you to avoid some errors before going to unit testing. It will cost boilerplate for auxiliary protocol declarations. In the example above you should declare union type explicitly:

trait Protocol
final case class First(message : String) extends Protocol
final case class Second(message : Double) extends Protocol

And you lose easy callback combination: no orElse method for you. Only hand-written

val receive : PartialFunction[Protocol, Unit] = {
   case First(msg) => receiveOne(msg)
   case Second(msg) => receiveTwo(msg)
}

And if you would like to add a bit of new functionality with trait Three then you would be busy with rewriting that boilerplate code.

Akka provides some useful predefined enhancements for actors. They add new functionality either by mixin (e.g. receive pipeline) or by delegating (e.g. reliable proxy). Proxy patterns are used pretty much in akka applications and they change protocol on the fly, adding control command to it. That could not be done that easily with typed actors. So instead of predefined utilities you would be forced to write you own implementations. And forsaken utilities would not be limited with FSM.

It is up to you decide whether typing improvement worth increased work. No one can give precise advise without deep understanding of your project.

Upvotes: 3

Konrad 'ktoso' Malawski
Konrad 'ktoso' Malawski

Reputation: 13140

I'd like to point out a confusion that seems to have surfaced here. Casper, the "typed actors" you refer to are deprecated and will be even removed eventually, I have explained in much detail why that's the case here: Akka typed actors in Java. The link you found with Viktor Klang answering, is talking about Akka 1.2 which is "ancient" as of now (when 2.4 is the stable release).

Having that said, there is a new experimental module called "Akka Typed", to which Daenyth is referring to in his reply. That module may indeed become a new core abstraction, however it's not yet ready for prime time.

I recommend you give the typed modules: Akka Streams (the latest addition to Akka, which will become not experimental very soon) and Akka Typed to see how Actors may become typed in the near future (perhaps). Then, actually look again at Actors and see which model best works for your use case. Untyped Actors have the advantage of being a true and tried mature module / model, so you can really trust them in that sense, if you want more types - Akka Streams has you covered in many cases, but not all, so then you may consider the experimental module (but be aware, we most likely will change the Typed API while maturing it).

Upvotes: 0

Daenyth
Daenyth

Reputation: 37461

Typed actors are very new; they're explicitly marked as experimental and not ready for production use.

Warning

This module is currently experimental in the sense of being the subject of active research. This means that API or semantics can change without warning or deprecation period and it is not recommended to use this module in production just yet—you have been warned.

(as of the time this is written)

Upvotes: 2

Related Questions