Hacker News Reader

Comment by moomin | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com