Thesis: http://mviering.de/reactiveruby.pdf

This is some interesting research, but for those hoping to code actual Ruby applications in a reactive style, I don't think this will give you all that you need. The main contribution here is to use a JIT with inline caches (Truffle VM) to optimize change propagation. That's some cool work, but it comes at a cost in flexibility and power, at least with the current state of the project. The framework supports only static graphs that only grow (no removing nodes), and changes must be single source (no "transactions" that handle several changes simultaneously). Those limitations are enough to make this probably not useful in "the real world." As a research project, though, using JIT w/ ICs to optimize propagation seems really promising.

Agreed that this is only research prototype with significant limitations at the moment. Dynamic changes to the graph should however be something in particular a dynamic optimization framework like Truffle can cope with.

Here's a hacky version of one of their examples, with "reactive Tcl", which is essentially powered by the trace command.

    proc timeB {varname seconds} {
        upvar $varname x
        set x [clock seconds]
        after [::tcl::mathop::* $seconds 1000] [list timeB $varname $seconds]
    }

    proc onChange {varname empty op} {
        upvar $varname x
        puts $x
    }

    timeB foobar 1
    trace add variable foobar write onChange

    vwait forever

Tcl - doing cool things before they were cool since 1990.

But it's not idiomatic Ruby. It's most basic issue is using camelCase method names. Definitely cool stuff though.

If you really, really wanted to stick to Ruby-like syntax for whatever reason, and you wanted to do "reactive programming", couldn't you just use Elixir?

A VM with soft-realtime semantics, OTP patterns as architectural building blocks, and an almost-too-easy path toward writing distributed applications.