Comment by dmitriid | Hacker News Reader

Comment by dmitriid | Hacker News Reader

A few problems I personally have with Rx are:

- 99.9999% of examples and tutorials on the internet fit one page of code. It's enough to look at something more complex, and you get immediately lost, because:

- Rx is very good at modelling streams that go in one direction, from A to B. From B to C. The to D etc. The moment you need the results of computation in C back in A... Oh, yikes. You start having Subjects everywhere (or BehaviourSubjects? Or ReplaySubjects? Or AsyncSubjects?) which may and will (if you are just starting learning these things) become extremely messy

- Rx may be easily viewed as async programming. Because your transformations happen at some unspecified non-deterministic point in time (and a lot of operations are async). So, debugging is hell. RxJS and (IMO) RxJava have tried to improve this, but it's still a mess. Properly structuring your code and streams so that you understand why and when a certain something happens? No one teaches you that. And you need that because your `.map(transform)` has no idea when and who invoked it. Etc.

- it doesn't help that Rx has cold and hot observables that everyone gets burned by. And I mean everyone. Oversubscription? Undersubscription? Events not firing? Events firing multiple times? These all happen. And some stream libraries go as far as not having cold observables at all. Good article about that: https://staltz.com/cold-and-hot-callbacks.html

- even such a fundamental thing as the concept of time may be screwed. See a primer on schedulers: https://staltz.com/primer-on-rxjs-schedulers.html

- My favourite thing: everyone tells you how easy and simple Rx is: it's just observables. In his book on RxJava the creator of RxJava says that it took him several months to understand Rx. While being tutored by one of the creators of ReactiveX. It's "easy and simple" in the same sense as "Haskell is easy and simple" or "rocket science is simple and easy" or <any branch of human knowledge> is simple and easy once you know and understand it.

All in all, streams of things are a good idea. Splitting your work into small isolated side-effect free chunks of work is a good idea. With Rx though, unless you are bright yourself or you have someone to mentor you, Rx is an unassailable bastion.

"- My favourite thing: everyone tells you how easy and simple Rx is: it's just observables. In his book on RxJava the creator of RxJava says that it took him several months to understand Rx. While being tutored by one of the creators of ReactiveX. It's "easy and simple" in the same sense as "Haskell is easy and simple" or "rocket science is simple and easy" or <any branch of human knowledge> is simple and easy once you know and understand it."

The problem here is that "simple" and "easy" are two completely different concepts. "Simple" is absolute, "easy" is relative. https://www.infoq.com/presentations/Simple-Made-Easy

Rx is neither simple nor easy, for non-trivial projects. Its an incredibly leaky abstraction and you end up having to understand the internals to do non-trivial things. Understanding when something runs in what thread (and in RxJava knowing when to use subscribe/subscribeOn/observeOn was much harder than it claimed to be), how to correctly handle errors, retry failed operations, apply backpressure without dropping data — these things essentially force you (in my experience, at least, but I’m no Rx expert, just used it for a few months) to dig into the internals to understand how they work: ie not simple.

But because of its lack of simplicity, it was also incredibly hard to use, to make it do what you want. So it was neither simple nor was it easy.

(And yes, I buy into the differences between simple and easy)

Points 2 and 3 seem (to me, I hope I'm not misunderstanding you) to be "fixed" by clojurescript's re-frame. You get a single queue of events that you define, based on what is relevant for your application, and you structure your app to cascade based on that stream. Creating a loop is some part of the app adding an event to the queue. And you are forced to keep functional code that only stores state in the app store tree. So you can easily know which event sequence makes a bug appear.

Even though Rx/ReactiveX is not easy and simple, it is a big improvement over traditional event-driven programming. The ideas behind Rx are also more general than, say, the actor model. Unfortunately, it is also easy to make a mess with Rx, and when that happens, the debugger is of little help. I often end up writing stuff to the console.

I have not found hot vs cold observables to be a problem in Rx (for C# or Java; I have never used RxJS). In fact, I often use "semi-hot" observables, such as what you get from a BehaviorSubject, which initially gives every new subscriber the latest/current value.

To me, the fact that "the concept of time may be screwed" when using Rx, is a good thing because of the flexibility it gives. In particular, it can be very useful for testing; but I do struggle with Rx scheduling at times. At some point there will hopefully be more information available on how to use Rx effectively in complex, real-life scenarios. Maybe someone should write a book on Rx design patterns?

Point 2 (and the difficulty of creating backpressure[1]) is what made my team rip RxJava out of a project and replace it with something resembling clojure’s channels (well, really queues that can be “closed” which would unblock any thread waiting on it). Awkward error handling too (errors typically killed a stream, re-establishing it was not always easy). We needed complex retry logic, which meant we needed to detect errors and funnel the error values back to the source to be retried later, after some timeout perhaps.

Maybe we were using RxJava wrong or weren’t knowleadgeable enough, but that’s part of my point: all of this was really hard for us in Rx and really easy once we could connect our logic through queues. Our code after ripping Rx out of the codebase looked quite similar: you could do queue.map(..).filter(...).moveTo(otherQueue) an so on. Its not identical to Rx, but its close enough that it only took 2 days to replace Rx with this, even though the project was quite large. You shouldn’t have to be an expert in Rx to use Rx. After about 4 months of using Rx every day, I was actually more confused than I was on day 1.

Another issue we had with RxJava was that stacktraces almost never pointed to where the error actually happened in code, because the context of where the error happened in code is the context of when the streams are set up, NOT the context of where the streams are executed (and RxJava’s constructs are incredibly deeply nested too, making the stacktraces huge).

We looked at a number of alternative libraries, but they were all too complex for our needs so we ended up writing a simple wrapper around queues that allowed us to “close” the queue (unblocking anything waiting on putting or getting) as well as to “complete” the queue, which would close the queueu for new puts but not for gets until its been drained. This took about a day for the initial implementation and two days to refactor our codebase to use this.

> - My favourite thing: everyone tells you how easy and simple Rx is

I joined the project and thought “wow! Rx is so simple! I love t!” and three months later, I hated Rx because of how complex it actually turned out to be. Rx is NOT simple for real world needs (back pressure that doesn’t drop data, error handling, retry logic)...

[1] RxJava has built-in backpressure support, but it was quite limited unless you jumped through hoops to implement your own data sources (sorry, I don’t remember the lingo). You could easily add throttling that would drop values, for example, but we found it really hard to have a->b and have a block until b can accept more. We first wrote a queue-based thing that would work with Rx since the queue would block if full, but it didn’t play well with Rx in the face of errors (if the stream died, then items on the queue got lost, iirc) and it was really hard to fix. Ripping out Rx and replacing it with our own little thing fixed all of these issues for us.

It is really interesting (and unfortunate) that you found it so hard to solve these issues within the framework of Rx(Java). Do you think they could be solved with minor adjustments to the framework, or is there a fundamental problem?

It’s possible that it could be solved, sure, but RxJava is complex and has so many layers of objects that it’s very difficult to trace what’s going on. As was mentioned above, the difference between hot and cold subscriptions and how hard it is (at least it was for me) to know what runs on what thread, all of these issues made it incredibly difficult to work with and I don’t see these things going away as they’re caused by fundamental design choices.

It would be easier, in my opinion, to design something that is like Rx and has a very similar api or feature set, but is architected to avoid these issues. We ended up building a system from queues which supported many of the operations Rx did (map, filter, join, merge, etc). I will say that our implementation wasn’t super efficient in terms of thread usage (it creates more threads than really necessary), but that could have been solved, it just wasn’t necessary for our needs.

Reply on news.ycombinator.com