Quasar and Akka – a Comparison

There a few other parts I take slight umbrage with (e.g. pretending Akka is heavyweight, has deployment rules, incomplete integration information, etc) but overall a nice informative comparison if a tad biased feeling.

BTW, no need to describe the implementation in terms of continuations. It's just enough (I think) to allocate function activation records on heap instead of statically allocated stack. (AFAIK continuations are also implemented similarly, although what I've read about Go, their call stack management is something more complex)

Also, I think the "actor model" is not the final solution for scalable distributed programming, it's just some initial, and IMHO pretty clumsy step. We will have better approaches soon.

A reason for choosing the asynchronous, callback-based approach has been that blocking plain OS threads entails significant overhead (as does the mere existence of many threads), which can be avoided with a non-blocking API. However, because Quasar – just like Erlang and Go – has true lightweight threads, blocking carries virtually no overhead

In my opinion the difference is much then whether an OS thread is blocked or not. Being able to make synchronous-looking (but not-thread-blocking) calls inside Actors still will block the Actor for other incoming messages for that amount of time. So you have states were the Actor is unresponsive - and with the right amount of dependencies between Actors you can deadlock.

A Actor which doesn't use any blocking calls internally will be more responsive and less prone to deadlock. But of course - you have to model more states explicetly. E.g. if I have an Actor routine that's like

  while true {
    var msg = await mailbox.Get();
    if (msg is XYZ) {
      var result = await doSthAsync()
      updateState(result)
    }
  }

This can be a good thing (you can be more responsive and all states are explicit) and also a bad thing (more verbose code).

Important is also that with the blocked Actor one get some kind of backpressure strategy for free. Whereas with the nonblocked Actor one has to handle that also explicitly.

I tried both concepts in my recent work, the blocked actor mainly with F#'s mailbox processor and the nonblocked with my own implementation and personally favor the second version now. I find it quite useful to think about and model Actors as state machines and beeing able to handle all kinds of state transitions explicitly. It also made deadlock prevention easier.

Nevertheless I'm seriously impressed about the capabilities of Quasar and Pulsar.

Akka follows the Erlang actor model pretty faithfully and what you do in the actor model is that you model state machines. In Scala you can also work with scala-async [1], which is basically what Quasar does, but that is not enough because calling a function and getting back some future result is only a really simple use-case, whereas in practice you get streams of messages and the communication is a bidirectional ping-pong.

So you work a lot with context become/unbecome [2], which is very much like what you'd do in Erlang for evolving state. This is because modeling a communication protocol requires multiple stages and a constant dialog with the other side. Even in a simple producer/consumers relationship you need back-pressure. Pretending that the communication is somehow synchronous is not going to fix the non-deterministic nature of this process and the logic will end up looking mostly the same. This is because it's not the asynchronicity that bites you ;-)

Quasar cannot make blocking I/O to not block threads, although it's clearly stated in the article, but that's just wrong. You can indeed patch connections to work with Quasar's fibers, working much like how you patch sockets in Python with gevent, so you can create your own JDBC data-source that plays nice, but that's not the same thing.

This really means that your pieces of I/O logic are still separated into blocking and non-blocking (red versus blue) and I'd rather see which is which by seeing `Future[T]` or `Observable[T]` in my function signatures. Therefore I disagree that Quasar code is more readable, but at least I'm willing to admit that YMMV.

Also, that Quasar actor given as an example has nothing to do with the actor model. This is because in the actor model the actors are untyped. If you type your actors, then you're not talking about the actor model anymore and you'd be better off with another computational model. At the moment it is completely futile to try to type state machines that work in a non-deterministic highly concurrent environment. And if you go through the effort of typing those actors, then you have to at least recognize that actors can communicate with multiple other actors at the same time and thus expose multiple interfaces. And then you can say that at the very least your typing says something more useful than Object or String.

I could write more, but I got tired.

[1] https://github.com/scala/async

[2] http://doc.akka.io/docs/akka/snapshot/scala/actors.html#beco...