Unfortunately a very common mixup. Here is Erik Meijer (aka headinthebox), the main guy behind Rx, talking about the difference[1]:
Let's keep "FRP" for what it really stands for in honor of it's inventor (http://conal.net/talks/). Rx is not FRP and was explicitly designed as a discrete collection API on purpose (as opposed to continuous time varying values).
...
Of course Conal no longer likes the name Functional Reactive Programming for what he did. And "Reactive Programming" was never really a good name for the non-continuous case either, it's really just a variant of dataflow programming.
> And "Reactive Programming" was never really a good name for the non-continuous case either, it's really just a variant of dataflow programming.
well, dataflow programming has always been central to reactive programming, isn't it ? that's what all reactive languages, Esterel, Lustre, etc. were about.
Yes, that's what I am saying, or rather: it's not "central to it", it is the thing itself.
"Reactive" is really just a re-branding of (synchronous) dataflow programming, and a fairly bad one at that because it just jumbles up and confuses so many things.
"Reactive" is/was really a type of system: one where you have continuous interaction with the outside world and the world generally cannot wait (similar but not identical to real-time). Contrasting with "transformational", where you just get some inputs turn them into outputs and are done, and "interactive", where you interact with the outside world but the world can wait.
It turned out that the synchronous dataflow languages (like Esterel, which is imperative, and Lustre, which is functional) had some fairly nice properties when it came to building reactive systems. As far as I know, Esterel is used for Airbus avionics...so the outside world really, really cannot wait :-)
How people somehow managed to mix up the style of system with the technology and then somehow also put in a claim that "functional" was an essential part of it is a little beyond me.
Sigh.