Push-based is an interesting choice here. I've built a couple push based reactive libraries myself, and they have some downsides which the authors don't seem to

Push-based is an interesting choice here. I've built a couple push based reactive libraries myself, and they have some downsides which the authors don't seem to address. Push often leads to wasted computations via updated values that don't end up getting used downstream either due to later updates affecting the same downstream nodes or simply because a value isn't being actively observed. Batching changes to signals can avoid the first cause (and it seems their execution model is implicitly batched by default?), but it doesn't solve the second. Push-Pull systems (which don't seem to be mentioned) solve this by pushing invalidation of signals down the graph, then on pull any signal that is invalid gets recomputed. Handling cycles in the reactive graph is also easier with this approach, rather than getting stuck in an infinite update loop, if something is invalidated it's consumers do not need to be invalidated again. I think the effort of creating RP languages is definitely a worth-while endeavor, but I'm not sure that they should have no imperative code, as seen with the recursive example taking things to the imperative or functional code level can have benefits. It would be interesting to see a language that is by default reactive, but has an escape hatch for imperative/functional logic.