Ask HN: What happened to Reactive Programming?
3 コメント
Just what your coworkers said, it's hard to maintain.
It still has it's application but it's quite hard to ultimately work with. For example, if something throws an exception, if you didn't setup the pipeline correctly it's stupidly simple to simply silently drop the exception all together.
And even when you haven't done that, it can be really difficult to understand why an exception has happened. You might be able to fairly decently get to the stage in the pipeline where the error came from, but working back to how the inputs got there in the first place can be really difficult.
More traditional programming is just a lot easier to work with. An exception getting thrown gives you a stack trace that gives a pretty clear picture of how you got to where you are at. And, putting in additional contextual information can make diagnosing everything a lot simpler.
I'll also just say, I find Rx (js, java, C#, etc) to be overly complicated in general. I'd suggest just trying some other reactive frameworks to see what I mean. Kotlin's Flow api is pretty good (IMO) and really makes a lot of struggles around learning Rx much easier to grok. I found that a decent part of what made reactive programming hard wasn't the reactive programming but rather Rx's implementation of it.
It still has it's application but it's quite hard to ultimately work with. For example, if something throws an exception, if you didn't setup the pipeline correctly it's stupidly simple to simply silently drop the exception all together.
And even when you haven't done that, it can be really difficult to understand why an exception has happened. You might be able to fairly decently get to the stage in the pipeline where the error came from, but working back to how the inputs got there in the first place can be really difficult.
More traditional programming is just a lot easier to work with. An exception getting thrown gives you a stack trace that gives a pretty clear picture of how you got to where you are at. And, putting in additional contextual information can make diagnosing everything a lot simpler.
I'll also just say, I find Rx (js, java, C#, etc) to be overly complicated in general. I'd suggest just trying some other reactive frameworks to see what I mean. Kotlin's Flow api is pretty good (IMO) and really makes a lot of struggles around learning Rx much easier to grok. I found that a decent part of what made reactive programming hard wasn't the reactive programming but rather Rx's implementation of it.
In practice, my experience is that it's mostly a lose-lose proposition. You have to invest in learning a bunch of same-but-difterent framework apis to do what the language already does natively. And in return, the code is more complex, and harder to debug, and so it has more bugs.
We once hired a very smart fellow to build out a media processing pipeline. He did with rxjs, but it wasn't scaling well. We tried to get with the paradigm for a bit and help scale it up, but flame graphs in profiler output were all crazy, and it was a pain to wire in timing traces, etc. We built a POC imperative version just to prove that we could indeed achieve the throughput we thought we could, and then we just said, well hey, this is faster and simpler, so... let's just go with this instead. And so we did.
We once hired a very smart fellow to build out a media processing pipeline. He did with rxjs, but it wasn't scaling well. We tried to get with the paradigm for a bit and help scale it up, but flame graphs in profiler output were all crazy, and it was a pain to wire in timing traces, etc. We built a POC imperative version just to prove that we could indeed achieve the throughput we thought we could, and then we just said, well hey, this is faster and simpler, so... let's just go with this instead. And so we did.
Yeah, forgot to mention that in my comment.
Tools are all built around non-rx workflows. That means doing things like performance work is a lot harder. Especially because RX is working on message passing it can be really tricky to figure out when a pipeline is ultimately stalling.
Tools are all built around non-rx workflows. That means doing things like performance work is a lot harder. Especially because RX is working on message passing it can be really tricky to figure out when a pipeline is ultimately stalling.
This is the first time I'm coming across this programming paradigm, it seems like it was trendy at some point [1], but the general consensus from the team is that it has become very hard to maintain, with a lot of side effects to manage.
Coming from an academic background and having some interest in functional programming, the idea seems interesting to me.
Does anyone still use this paradigm day-to-day (any example codebases, documented projects, tips on maintaining complex reactive projects in JavaScript would be appreciated) or has it mostly been moved away from?
[1] https://trends.google.com/trends/explore?date=all&q=%2Fm%2F02vz4nz&hl=en-US