ReactiveX programming isn’t FRP.

Research into Functional Reactive Programming was popularized by Conal Elliot back in 2008 - though it actually goes back to his 1997 paper “Functional Reactive Animation” with Paul Hudak.

The Essence and Origins of FRP

Hmmm…

Reactive Extensions solve certain problems well in certain environments.

It just so happens that being “reactive” is only one single concern that any Erlang/Elixir solution design/architecture has to address. How “reactive” a solution is depends on certain design choices.

But in my opinion a problem that Rx is suited for is probably too large to fit in a single BEAM process (where everything happens sequentially) and once you break up the problem across multiple BEAM processes the use case for Rx typically goes away.

Some data stream transformation can be handled with GenStage - visualization would likely be a separate (front end) concern but I guess Phoenix channels could be used to inform the users of the transformation progress.

Imagine a BEAM process for every active cell in a spreadsheet - only each process can send an event to any other process that it knows about; incoming events are (usually) processed in the order they arrive; typically a single process has more responsibility than a single spreadsheet cell. Code execution within any one process is strictly sequential. Concurrency happens between processes.

For the time being you can use Pyrlang to reuse what you already have - then Erlang/Elixir can interact with that Python code (and the C code doing the real work) just like with any other node.

See also Elixir call python by ports.