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.
Timothy
On Mon, Dec 16, 2013 at 9:09 PM, Michal Till <michal.t...@gmail.com> wrote:
> Hello,
>
> I seem to be a little bit confused when comparing core.async to the so
> called Reactive Extensions (Rx). They seem to tackle similar problem of
> async-icity, so I wonder what are the principal differences and in what
> cases is one preferred over the other. Can someone please explain?
>
> Regards,
> Michal
>
> --
> --
> 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.
>
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
--
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.
