Distributed Actors in Java and Clojure | Hacker News Reader

Distributed Actors in Java and Clojure

blog.paralleluniverse.co

71 pointspron14 comments

Why should I pick this over Akka's incredibly performant and battle tested actors?

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

https://news.ycombinator.com/item?id=5647310

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.

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).

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.

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...

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.

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.

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.

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.

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.

I confess I had the exact same thought as moomin. The context (how your project relates to core.async) is valuable to have, and it may be worth going back and adding it to your blog post.

Also, just as sort of a "marketing" thing, the Quasar/Pulsar thing is confusing. I've seen mention of your project before and I always find it confusing how it has two names. I forget which one is which. It might be worth picking one name for just the whole package.

In both cases I give you this non-technical feedback because I would hate for your efforts to get overlooked just because developers don't understand why your project is important and/or can't remember its name so go with something else.

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?

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

Reply on news.ycombinator.com