| The article is full of incorrect statements and biased opinions, I stopped reading at some point, because even though I think Quasar is really interesting, this article has been a turn off. Some things that bothered me ... 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... |
scala-async looks more like core.async's go to me, i.e. it macro-transforms blocks of code that include special constructs into some continuation-passing style. Quasar implements lightweight threads on the JVM (via bytecode instrumentation, which is a language-independent mechanism), and this is a different thing: no special constructs are needed, you just write regular blocking code (only in lightweight threads, that have basically the same interface and usage as regular Java threads) using normal method calls and control flow constructs. Quasar will take care of blocking/resuming/scheduling efficiently.
As for I/O, Quasar integrations allow lots of fibers to make blocking calls _without_ as many OS threads blocking. The underlying implementation mechanism is often to tap into an async API, suspending fibers when an async call is started and installing an handler that will resume them when the async call completes. Quasar includes such an integration with Java NIO for files and sockets and more are available in Comsat (e.g. with servlet async, async HTTP clients etc.).
I agree about typed actors not being too helpful in dynamic, complex and highly concurrent environments, but in some situations (e.g. transient one-receive actors) they can help keeping communication in check more statically. Of course one can just avoid using types if not needed and Quasar behavioural actors are actually untyped.