On 12/17/13, 6:33 AM, Timothy Baldridge wrote:
I won't go so far as to tell you which is better as that often comes
down to a matter of taste. However, I will explain the technical
differences. In this case I'll use my (somewhat limited) knowledge of
C# Rx. Scala/Java's Rx may be different.
Rx is based on a direct call. We could write a simple version of Rx
thusly:
(defprotocol IObservable
(on-next [this val])
(attach [this obs]))
(defn filter [f]
(let [a (atom #{})]
(reify IObservable
(on-next [this val]
(when (f val)
(doseq [i @a]
(on-next i val))))
(attach [this obs]
(swap! a conj obs)))))
As you can see, each parent in the tree directly calls the child via
the on-next (or on-error and on-exit in a real Rx impl). Thus it's
pretty simple to run something like this without a thread pool or
dispatcher. But what happens if calling on-next throws an exception?
In that case the error bubbles up the wrong way. That is to say, the
data goes down the data graph while errors go the opposite way. C# Rx
has some code to handle things like this and populate errors the right
way.
In addition it can be possible for multiple threads to be executing
on-next at the same time. It all depends on the semantics of whatever
is calling the top level on-next.
Core.Async on the other hand is based on two primitives: channels
(queues) and processes. Errors are never propagated unless specified
by the user. And thread pools/dispatchers are almost always required.
With core.async we could implement filter thusly:
(defn filter [f in-c out-c]
(go-loop []
(when-let [v (<! in-c)]
(when (f v)
(>! out-c v)))))
Here we accept the input and output channels as arguments and then
create a process that connects the two. Since the go-loop is a single
thread only one message is in-flight in the body of this go at a
single time. If we want more parallelism, we simply call this filter
function multiple times to create multiple gos.
So that's the difference. Rx creates graphs of objects, while
Core.Async (and CSP in general) creates graphs of processes connected
by queues. CSP seems a bit more general to me, but many would probably
disagree with me on that one.
Having used both I would agree that CSP is more general and when you
need to do custom logic it tends to be easier, IME, than Rx. Another key
difference is that Rx is only about one way communication within a
single subscription. Once you need to have bi-directional communication
CSP is a better tool for the job.
-Ben
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
