FRP is about streaming events and behaviours through pure functions. The Actor model - at least, as implemented in Akka - is about streaming immutable messages (which can be considered to be discrete events) through potentially impure objects, called actors.

So on the surface they seem related.

What else can we say about how they related? Also, what can say about which of them might be more appropriate for different application domains?


2 Answers 2


Neither actors nor FRP are about streaming. Actors don't even support external configuration of an output stream.

FRP is strongly characterized by its modeling signals and events on a linear timeline, which enables FRP behaviors to compose in a deterministic manner. Actors are strongly characterized by processing messages in non-deterministic order, and have scarcely any compositional properties (i.e. you can't treat an arrangement of two actors as a larger actor).

If you're seeking similarities, both actors and FRP have a close relationship to lambda calculus. Both can model systems responsive to human input. Both support modeling of internal (local) state.

FRP supports local state through integrals or accumulators (fold over time), while actors model supports state by allowing each actor to specify its behavior for the next message in response to the current one. This pervasive support for local state makes both FRP and Actors inadequate for live programming (or runtime upgrade of program code); it becomes too easy to lose important state.

Regarding application domains:

Actors model is well suited for open systems, where we might wish to install or maintain actors at runtime. Actors model is also weakly suited to distributed systems, as the non-deterministic ordering of messages can make a conforming implementation easier. (The reason actors are not more strongly suited to distributed systems is that ensuring a message arrives 'once and only once' is quite difficult in the face of disruption, and actors also tend to require distributed GC, which is a pain.)

FRP is well suited to closed systems that operate over time - e.g. robotic controllers, music programming, computational toys. The determinism and compositional features make FRP more convenient to work with than actors, at least in those cases where FRP can directly model a solution. Integrating FRP with effects (elegantly, without hacking the model with impurity) has proven difficult. There has been recent work on effectful FRP via 'wormholes' - effectively, unique or linear typed access to resources.

There are other models that lie somewhere between FRP and Actors.

Flow Based Programming (FBP), developed by John Paul Morrison, really does support streaming of messages.

Time Warp protocols (or the more recent work on Lightweight Time Warp (LTW)) places actors-like messages on a logical timeline to provide a more controlled and compositional notion of message passing. Time warp is often used for large parallel and distributed systems, e.g. scientific computing. The original time warp was unsuited for interactive simulatons (responsiveness to human input), and LTW is only marginally suited.

I am developing Reactive Demand Programming (RDP) which enables responsive, compositional, FRP-like manipulation and processing of signals in open and distributed systems, and eliminates local state. RDP is achieved by constraining side-effects to commutative, idempotent influence on resource state by signals over time. RDP requires rethinking of resource and state models.

  • $\begingroup$ One thing I'm not happy with about FRP is that mapping a function over an event takes a finite amount of time, yet FRP will consider the resulting event to have happened at the same time as the original event. This can lead FRP's internal notion of time to get out of step with wall time, and in particular could cause events to be wrongly ordered with respect to wall time. I also don't like the fiction that event B can happen after event A, but at the same internally-recorded time as event A. $\endgroup$ Jan 19, 2013 at 18:39
  • 1
    $\begingroup$ @RobinGreen The ability to model 'instantaneous' progression or transformation of events is quite useful. Developers are free to compensate by modeling delay either up-stream or down-stream. With dependent or linear types, one could develop a notion of time-safety (real-time properties; allocation of latency as a resource) for FRP systems that would be difficult to model in atemporal systems. $\endgroup$
    – dmbarbour
    Jan 19, 2013 at 20:12
  • $\begingroup$ @RobinGreen - regarding "the fiction that event B can happen after event A, but at the same recorded time", the notion of events occuring in instantaneous or transcendental time (lim(x->0+)(T+x)) is one of the universal fallacies of the 'event' abstraction. The ordering of events when duplicating, splitting, and merging event streams becomes arbitrary, inconsistent, easily loses temporal information. (cf. Why Not Events) $\endgroup$
    – dmbarbour
    Jan 19, 2013 at 20:46
  • $\begingroup$ Are you morphing your RDP project into the Awelon project? $\endgroup$ Oct 1, 2014 at 6:43
  • 1
    $\begingroup$ Awelon project will make heavy use of the RDP model/paradigm. Think of RDP in a manner similar to OOP. A programming model has implications on architecture and language design, but isn't something I'd call a 'project'. $\endgroup$
    – dmbarbour
    Oct 1, 2014 at 15:41

I wanna point out how they are different from a practical point of view:

1) actors send messages to other actors, this message passing is described explicitly and imperatively.

For example:

send msg to Actor137.

2) in FRP the data flow is described declaratively:

For example:


The message passing is handled by the FRP framework and you don't have to describe "manually" how to pass messages from one cell (akin to Actor, encapsulates state, aka Behaviour) to another.

In other words:

The essence of functional reactive programming is to specify the dynamic behavior of a value completely at the time of declaration. So all dependencies of Cell134 are defined at declaration point.

This is not true for the actor model. Actors influencing the behaviour of an actor A are not defined at the same place in the source code where the actor A is defined.

Recently I noticed that there is an interesting hybrid between the two: Akka streams, where the dataflow is described declaratively but is implemented using actors.

Another difference is : Actors tend to be async while FRP tends to be synchronous (often glitch free).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.