Reactive (Dataflow) Programming in Java and Clojure with Quasar and Pulsar | Hacker News Reader

Reactive (Dataflow) Programming in Java and Clojure with Quasar and Pulsar

blog.paralleluniverse.co

71 pointspron18 comments

What's the performance characteristics of Pulsar vs. core.async like?

I did a benchmark a while ago. If your go blocks block a lot and communicate with many other go blocks, then Pulsar can be much faster (without changing your code if you're using Pulsar's core.async API). If they don't, then core.async can be faster than Pulsar if you're using Pulsar's default scheduler, which is based on ForkJoinPool, or a little slower than Pulsar when using an ExecutorThreadPool-based scheduler to schedule the fibers (see the UI example in the post on how to create and assign schedulers).

How is Quasar vs Akka?

I'm not sure whether Akka supports reactive programming or not, but the main difference is that Quasar has true lightweight threads which means CSP like in Go, and actors just like in Erlang (Quasar actors can, and should, block, they have selective receive just like Erlang etc.). Also, I think Akka has a distinct Scala feel even to its Java API.

http://typesafe.com/platform/runtime/akka

http://en.wikipedia.org/wiki/Reactive_programming http://en.wikipedia.org/wiki/Functional_reactive_programming

http://www.reactivemanifesto.org/

http://vimeo.com/user18356272/review/66548920/f93e3fa7d9

http://letitcrash.com/

The "reactive" in the "reactive manifesto" shares only the name with reactive programming, nicely explained in the Wikipedia articles you link to (which are also linked in the article).

Same goes for Akka. I don't know if it supports reactive programming (despite the use of the word "reactive" in the materials you linked to), but none of the links you supplied suggests that it does.

Are those really that different? Sure, the manifesto spends more time showcasing the benefits of a reactive system than explaining how it works, and that explanation takes the form of an event-based view.

But event propagation ''is'' a way to transfer change throughout a system built on data flows, so it fits the definition of the reactive parading. In doing so, the manifesto could be seen as a particular way to realize RP, a subset of a larger concept.

Am I missing something? Why do you consider they don't have anything in common but the name?

Because reactive programming is a pretty specific (though not overly specific) programming paradigm, while the manifesto talks about ideals in software design. You can achieve these ideals with or without reactive programming, and you can use reactive programming without aiming for those ideals.

Both are nice, but they're two different things.

How do you define reactive programming?

As a model in which you define dependencies among different changing variables, and any change in the value of a variable – which can happen at any time, even concurrently with other variable updates – triggers the re-computation of all dependent values.

To be honest I'm not even sure what reactive programming means. I took the Reactive Programming course from Coursera, by Odersky, Kuhn & Meijer, and in the forums Kuhn explicitly said it's not functional reactive programming.

I'll admit I'm confused by the relationship between FRP, RP and Akka's brand of RP. The only thing I'm certain is that Akka's RP != FRP. The assignments from the course were full of side-effects, mutability and global variables.

Rx is not FRP, for sure, but even most impure FRP systems (like flapjax) are not really FRP given a pure definition.

"Reactive" is quite vague. The earliest programming systems labelled "reactive" were meant for expressing low level real time control behavior, but these days the word could just as well be related to UI or enterprise/web data processing (note, that the above projects don't really help with UI, they are more for the latter!).

It's been a while since I looked, but the best reactive library I've seen built on Akka is the Play framework one. They were working to separate it out from the framework as library only code, but I'm not sure the state of that effort.

Play has composable futures (like JDK 8's CompletionStage) which are indeed a component of FRP. I don't know if it's got something similar to Rx's Observables, which let you compose streams of values. Also, it's tied to HTTP services and isn't a general-purpose FRP solution, which is why I didn't mention it in the post.

[1] http://download.java.net/jdk8/docs/api/java/util/concurrent/...

Play's futures are just Scala futures, they aren't tied to HTTP requests.

I was thinking more of their iteratee stuff:

https://github.com/playframework/playframework/tree/master/f...

Again, don't know the state of pulling it apart but earlier versions were tied to Play in name only.

The first example of reactive programming in Wikipedia is the ability to define a = b + c, where b and c are changing (and a is changing with them. In Quasar, you can do it imperatively:

  for(;;)
      a.send(b.receive() + c.receive();

Or functionally:

   zip(b, c, (x, y) -> x + y);

RxJava also lets you do the latter. I see that it could also be achieved with a combination of Iteratees and Enumeratees in the code you linked to, using an approach similar to RxJava's, only more complicated and with fewer features.

Why would you claim composable futures are indeed a component of FRP? I find no mention of this in Elliott's and/or Hudak's description of FRP.

Edit:

Conal adds a notion of future values in his push/pull work, but I wonder if it is the same thing as being discussed here, as composable futures were around long before FRP:

http://conal.net/papers/push-pull-frp/push-pull-frp.pdf

Reply on news.ycombinator.com