
Distributed Actors in Java and Clojure - pron
http://blog.paralleluniverse.co/post/56519815799/distributed-actors-in-java-and-clojure
======
octo_t
Why should I pick this over Akka's incredibly performant and battle tested
actors?

~~~
pron
Actors are just a part of Quasar. There's a lot more you can do with true
lightweight threads. Stay tuned for more posts.

------
moomin
This probably came out at the exact wrong time for Clojure. At the moment all
the attention is on core.async. It'd have to offer something quite special to
supplant it.

~~~
pron
It doesn't supplant core.async -- it extends it. Pulsar includes a compatible
implementation of the core.async API
([http://puniverse.github.io/pulsar/manual/async.html](http://puniverse.github.io/pulsar/manual/async.html)).

We like core.async because it can be used in ClojureScript, but Quasar/Pulsar
can be used by any JVM language. You can use the Pulsar implementation of
core.async to communicate with Java or Ruby code. Plus, it's much more
performant than core.async when there's a lot of interaction between go
blocks. It also works in a cluster.

So, core.async for the browser, and Pulsar's compatible core.async for the
JVM. core.async is also just a small part of Pulsar (Quasar/Pulsar have what
we call fiber-blocking IO, a full Erlang-like actor system and more[1]). We
promise to keep our core.async implementation fully compatible with the API,
so you don't have to change APIs if you don't want to.

[1] One of the most exciting differences is that Pulsar fibers (each go block
runs in a fiber) are not limited to a single Clojure expression. This means
that you can run a complete ring handler inside a go block.

~~~
moomin
Interesting. But a library author still needs to choose between one and the
other and you can't inter operate between the two (correct me if I'm wrong). I
wonder if now might not be a good time to talk to the Clojure core guys and
see if there's a way to make this pluggable.

My ideal would be to have a situation like Jetlang, in which the app owner
could mix and match policy. It'd be nice to be able to use Akka as well...

~~~
bkirkbri
I believe that core.async leverages Clojure Protocols to enable you to use
whatever back end implementation you like. The Quasar guys just implemented
those protocols.

~~~
_halgari
not true at all. Quasar uses byte code manipulation, core.async uses Clojure
macros to pre-process code. The Quasar code is a re-implementation of the
client end api, not the underlying protocols.

~~~
pron
That's right. Pulsar re-implements core.async on top of its own lightweight
threads. Nevertheless, we aim to make it so that any code written using
core.async could easily use Pulsar instead.

We implemented core.async because we saw it could be easily done, but Pulsar's
goals are broader. Frameworks like Akka give you actors, core.async gives you
go blocks and channels, and Scala's async gives you async blocks and futures.
In Quasar/Pulsar these are all special cases of lightweight threads. Once you
can run 100Ks or 1M threads on a single machine, all sorts of possibilities
are open to you.

~~~
moomin
I understand that you have wider ambitions, but on this point I think you're
misunderstanding how libraries are used (something that is sadly common in
library authors). If libraries were only ever used by applications, your
solution would work: you just swap one namespace for another. A slight pain,
but nothing too outrageous.

The problem is, give it six months and there will be many libraries that
themselves use core.async. The application developer then either can't use
those libraries or has to fork them herself. This just isn't going to happen,
so everyone ends up with the default implementation.

Thinking about it, it might be possible to write a lein plugin that intercepts
load-library and puts in your own implementation. That might actually work.
That or engage the clojure.core team and get some redesign on core.async so
that it's pluggable at an application layer.

Please don't take this as blind criticism. Quasar looks really interesting and
I'd like to see app developers be able to easily use it from Clojure.

~~~
pron
Yes, we've though about that. What we'll probably do is provide a "core.async"
namespace. All you'll have to do is replace the name of the dependency in the
leiningen project file.

Keep in mind, though, that Clojure, while our favorite language, is still
quite small (adoption wise) compared to other JVM languages. Java and Ruby are
at least as prominent on our roadmap.

BTW, love your username.

------
werg
Initially when I read the title my mind jumped to assume that you were doing
actors distributed across multiple machines, i.e. one actor spread out,
possibly in some fault-tolerant, eventually consistent way, in a cluster. But
this actually means local actors, accessible across a network, right?

~~~
pron
Correct. It's just actors on different machines talking to one another - just
like in Erlang.

