FBP (Flow-Based Programming) is often conflated with Actors.
Actors are often conflated with Erlang.
I discuss some of the issues in this essay.
I have found that one can reason (understand) a program if it doesn't cross the great divide.
The great divide is delimited by the use of CALL/RETURN.
If a program doesn't use CALL/RETURN, one can reason about it.
If a program uses CALL/RETURN, then all bets are off.
Most programming languages expect programmers to implement functions using CALL/RETURN, e.g. f(x); is usually implemented using CALL / RETURN (the caller calls the function f and waits for a result). [N.B. Recursion is CALL/RETURN. Smalltalk "message passing" is actually CALL / RETURN].
Using CALL/RETURN, it is "natural" to skip over the fire-and-forget (concurrency) paradigm. I discuss this issue further in my essay about CALL RETURN SPAGHETTI https://guitarvydas.github.io/2020/12/09/CALL-RETURN-Spaghetti.html.
CALL RETURN uses a global variable to store breadcrumbs.
This global variable is created/supported by most modern hardware.
I discuss this issue in my essay ALGOL Bottleneck https://guitarvydas.github.io/2020/12/25/The-ALGOL-Bottleneck.html.
Closures are a way to escape the CALL/RETURN handcuffs.
In fact, processes in operating systems, are just honking big closures.
Actor technology does not specify CALL / RETURN.
Erlang implements its processes using its BEAM VM.
Erlang expects programmers to explicitly create processes using spawn.
Erlang also allows creation of "smaller" closures, using fun.
Erlang uses immutable data. This is not strictly necessary, since isolation hides the inner workings of components.
Erlang allows hierarchical decomposition of processes, but does not encourage it.
Erlang allows knowing the pid of a process, hence, allows dynamic reconfiguration of the architecture. [Dynamic reconfiguration is frowned upon from a Maintenance Engineering perspective. Dynamic reconfiguration makes explicit Architecture difficult if not impossible. Self-modifying code is an example of dynamic reconfiguration and can, also, lead to self-modifying architectures.]
Erlang defines a number of basic types. This encourages programming Implementation instead of Engineering and Architecture.
FBP (Flow-Based Programming) encourages CALL RETURN-less construction of systems.
FBP has been implemented on top of other, existing, base languages. As soon as one writes programs in the base language (beyond the FBP paradigm), on returns to CALL/RETURN-full programming.
FBP provides Isolation by implementing components as operating-system supports processes.
I favour hierarchy.
From this perspective, processes should be composed of other processes to a very deep level.
FBP, Actors and Erlang support hierarchical organization of programs, but do not otherwise encourage this style.
FBP goes beyond Actors and Erlang, by providing the concept of sub-nets. Coordination of child processes is left to the programmer.