News for hackers. Stuff that matters.
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by weavejester on Thursday February 20, 2014 @03:35PM (#7273376)
What's the performance characteristics of Pulsar vs. core.async like?
[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by pron on Thursday February 20, 2014 @03:42PM (#7273414)
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).
[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by namelezz on Thursday February 20, 2014 @01:31PM (#7272642)
How is Quasar vs Akka?
[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by pron on Thursday February 20, 2014 @01:37PM (#7272685)
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.
[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by pron on Thursday February 20, 2014 @02:07PM (#7272869)
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.

[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by TuringTest on Thursday February 20, 2014 @02:58PM (#7273153)
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?

[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by the_af on Thursday February 20, 2014 @03:19PM (#7273273)
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.

[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by seanmcdirmid on Thursday February 20, 2014 @06:54PM (#7274514)
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!).

[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by pron on Thursday February 20, 2014 @03:04PM (#7273190)
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.

[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by mattcarkci on Thursday February 20, 2014 @06:34PM (#7274426)
How do you define reactive programming?
[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by pron on Thursday February 20, 2014 @07:44PM (#7274726)
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.
[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by kasey_junk on Thursday February 20, 2014 @03:02PM (#7273179)
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.
[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by pron on Thursday February 20, 2014 @03:24PM (#7273299)
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/...

[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by seanmcdirmid on Thursday February 20, 2014 @06:56PM (#7274526)
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

[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by kasey_junk on Thursday February 20, 2014 @03:30PM (#7273332)
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.

[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by pron on Thursday February 20, 2014 @03:38PM (#7273388)
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.
[ Parent | on HN ]
Re:Reactive (Dataflow) Programming in Java and Clojure with ... by saryant on Thursday February 20, 2014 @03:28PM (#7273320)
Play's futures are just Scala futures, they aren't tied to HTTP requests.
[ Parent | on HN ]