Comparing core.async and Functional Reactive Programming (+Rx)
I think main problem is your assumption about the tackled problem are not quite so, since none of them are tackling the asynchronicity "problem".
The abstractions
FRP main idea is propagation of change, think about accomplishing the same thing Excel does, where you define cells depending on each other in a cascade, and when one cell changes, all the dependent cells on the cascade are recalculated.
core.async main idea is systems decomposition, think as separating concerns using a queue in the middle of different processes, in core.async case instead of queues you have channels but you get the idea.
So, removing the pyramidal code is not the objective of either technology, and they operate on different abstraction layers.
About complecting control flow
The idea about complecting communication and flow control is taken from the original core async post.
While there are various mechanisms to make events/callbacks cleaner (FRP, Rx/Observables) they don't change their fundamental nature, which is that upon an event an arbitrary amount of other code is run, possibly on the same thread, leading to admonitions such as "don't do too much work in your handler", and phrases like "callback hell".
Rephrasing, if you have business domain code inside an event handler, you have complected the X event processing with the what to do when X happens.
Which is what core.async tackles, since introducing a queue/channel in the middle, helps for a better separation of concerns.
Implementation
All your questions regarding callbacks and passing observable endpoints as parameters are just implementation questions, it really depends on the Rx implementation and API.
If you look at React reusable components you really don't have much of a callback hell to be seen, and you get that idea of passing observables around.
Final thoughts
Even if Rx can be used to model any data flow, is more commonly used for UI Rendering a-la Excel, to simplify how you update your view when your model changes.
On the other hand, Core.Async can be used to model separation of concerns when any two sub-systems communicate with each other (same usage scenario as queues), using it on the UI rendering chain main idea is to separate:
- Server side event generation and processing
- How that event affects your model
So you can have core.async and FRP together, since core.async will separate concerns, and FRP will define your cascading data-flow once your model is updated.
At least one of the main principal differences, and, I think, what Rich ment by "[FRP] complects the communication of messages with flow of control", is the following.
Callbacks are code that is executed. And that execution has to happen in some thread at some point in time. Often, the time is when the event happens, and the thread is the thread that notices/produces the event. If the producer instead put a message on a channel, you are free to consume the message when you want, in whatever thread you want. So callbacks, which are essentially a form of communication, complect the communication with flow of control by dictating when and where the callback code is being executed. If you have to use callbacks for whatever reason, just use them to put a message on a queue/channel and you are back on track.
Because core.async is less complex, it should be preferred as long as there is not a good reason to use the alternatives.
Clojure core.async is a port of go blocks from the Go language. The fundamental concept is channels representing asynchronous communication between threads.
The goal is to be able to write normal looking blocks of sequential code that access channels to get input, and this is seamlessly translated into a state machine that works out the CSP translation for you.
Contrast to FRP, which is still fundamentally about callbacks, and it complects the communication of messages with flow of control. core.async eliminates callbacks from your code entirely, and separates control flow from message transmission. Also, in FRP a channel is not a first class object (ie. you cannot send an FRP channel as a value on an FRP channel).
EDIT:
To answer your questions:
-
Yes, many times, callbacks can be eliminated, for example with retry logic, distinctUntilChanged and lots of other things such as:
var obs = getJSON('story.json').retry(3);var obs = Rx.Observable.fromEvent(document, 'keyup').distinctUntilChanged(); I'm not sure what that refers to with making it more complex with flow control.
Yes, you can pass around an object like you would a channel, as with the below object.
For example, you can have channel like behavior here using RxJS with a ReplaySubject:
var channel = new Rx.ReplaySubject();
// Send three observables down the chain to subscribe to
channel.onNext(Rx.Observable.timer(0, 250).map(function () { return 1; }));
channel.onNext(Rx.Observable.timer(0, 1000).map(function () { return 2; }));
channel.onNext(Rx.Observable.timer(0, 1500).map(function () { return 3; }));
// Now pass the channel around anywhere!
processChannel(channel);
To make it a little bit more concrete, compare the code from David Nolen's post here with an RxJS FRP example here
There is a post here that compares FRP with CSP on a limited set of examples (which however meant to demonstrate benefits of CSP), with a conclusion at the end: http://potetm.github.io/2014/01/07/frp.html