Debate reactive programming with me!
-
The Reactive Manifesto ([https://www.reactivemanifesto.org/\](https://www.reactivemanifesto.org/)) is several paragraphs long and lists a large number of alleged characteristics and advantages of reactive programming; so many in fact, that reactive programming appears to be offered as some sort of panacea that will solve all of our problems forever. To me it seems that most of the alleged advantages of reactive programming as listed in that manifesto are either false, or non-sequiturs, so despite what the manifesto says, I posit that the sole purpose of existence of reactive programming is performance, in other words saving threads. Incidentally, this means that in any environment that offers virtual threads (for example, in Java starting from version 19) reactive programming is irrelevant. Change my mind. P.S. Unfortunately, when people become salespersons for a certain cause, they seem to be never content with just mentioning the one game-changing advantage of their product over the competition; they seem to always want to throw as much as possible at the customer, hoping to make them buy; so, they tend to include a torrent of inconsequential or even entirely fictitious advantages, which often has the effect of drowning the one important advantage in the noise. For example I have seen this with microservices, whose lists of advantages are often twenty items long; most of them are preposterous, and almost all of them are nothing but filler, because in fact microservices only have one game-changing advantage, which is scalability, or two if we want to also count resilience.
-
The Reactive Manifesto ([https://www.reactivemanifesto.org/\](https://www.reactivemanifesto.org/)) is several paragraphs long and lists a large number of alleged characteristics and advantages of reactive programming; so many in fact, that reactive programming appears to be offered as some sort of panacea that will solve all of our problems forever. To me it seems that most of the alleged advantages of reactive programming as listed in that manifesto are either false, or non-sequiturs, so despite what the manifesto says, I posit that the sole purpose of existence of reactive programming is performance, in other words saving threads. Incidentally, this means that in any environment that offers virtual threads (for example, in Java starting from version 19) reactive programming is irrelevant. Change my mind. P.S. Unfortunately, when people become salespersons for a certain cause, they seem to be never content with just mentioning the one game-changing advantage of their product over the competition; they seem to always want to throw as much as possible at the customer, hoping to make them buy; so, they tend to include a torrent of inconsequential or even entirely fictitious advantages, which often has the effect of drowning the one important advantage in the noise. For example I have seen this with microservices, whose lists of advantages are often twenty items long; most of them are preposterous, and almost all of them are nothing but filler, because in fact microservices only have one game-changing advantage, which is scalability, or two if we want to also count resilience.
Sorry, I'm not familiar with reactive systems but the reference you gave is just a bunch of gobbledygook. Platitudes and truisms not a design method make. I spent many years in real-time data acquisition world and all the stuff mentioned in the "manifesto' was so obvious that no one would even bother to mention it: - Responsive: show me a real time system that is not responsive - Resilient: nah, we'll just let our system crash at the first bad input - Elastic: we had to wait for 2014 for someone to bring up the subject because we never heard of the code 1201 and 1202 errors in '69[^] - Message driven: another novelty... who would have thought?! Laughable!
Mircea
-
The Reactive Manifesto ([https://www.reactivemanifesto.org/\](https://www.reactivemanifesto.org/)) is several paragraphs long and lists a large number of alleged characteristics and advantages of reactive programming; so many in fact, that reactive programming appears to be offered as some sort of panacea that will solve all of our problems forever. To me it seems that most of the alleged advantages of reactive programming as listed in that manifesto are either false, or non-sequiturs, so despite what the manifesto says, I posit that the sole purpose of existence of reactive programming is performance, in other words saving threads. Incidentally, this means that in any environment that offers virtual threads (for example, in Java starting from version 19) reactive programming is irrelevant. Change my mind. P.S. Unfortunately, when people become salespersons for a certain cause, they seem to be never content with just mentioning the one game-changing advantage of their product over the competition; they seem to always want to throw as much as possible at the customer, hoping to make them buy; so, they tend to include a torrent of inconsequential or even entirely fictitious advantages, which often has the effect of drowning the one important advantage in the noise. For example I have seen this with microservices, whose lists of advantages are often twenty items long; most of them are preposterous, and almost all of them are nothing but filler, because in fact microservices only have one game-changing advantage, which is scalability, or two if we want to also count resilience.
-
The Reactive Manifesto ([https://www.reactivemanifesto.org/\](https://www.reactivemanifesto.org/)) is several paragraphs long and lists a large number of alleged characteristics and advantages of reactive programming; so many in fact, that reactive programming appears to be offered as some sort of panacea that will solve all of our problems forever. To me it seems that most of the alleged advantages of reactive programming as listed in that manifesto are either false, or non-sequiturs, so despite what the manifesto says, I posit that the sole purpose of existence of reactive programming is performance, in other words saving threads. Incidentally, this means that in any environment that offers virtual threads (for example, in Java starting from version 19) reactive programming is irrelevant. Change my mind. P.S. Unfortunately, when people become salespersons for a certain cause, they seem to be never content with just mentioning the one game-changing advantage of their product over the competition; they seem to always want to throw as much as possible at the customer, hoping to make them buy; so, they tend to include a torrent of inconsequential or even entirely fictitious advantages, which often has the effect of drowning the one important advantage in the noise. For example I have seen this with microservices, whose lists of advantages are often twenty items long; most of them are preposterous, and almost all of them are nothing but filler, because in fact microservices only have one game-changing advantage, which is scalability, or two if we want to also count resilience.
My apps reflect all the characteristics refered to as "reactive" though I never though of labeling them as such: - Responsive: sub 100ms response time - Resilient: graceful degradation in the face of system issues - Elastic: a frame rate that accomodates an increased load - Message driven: all operations that need to be async are so So, "reactive" seems to be a new word to describe what should have been taken for granted in any worthwhile app.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
The Reactive Manifesto ([https://www.reactivemanifesto.org/\](https://www.reactivemanifesto.org/)) is several paragraphs long and lists a large number of alleged characteristics and advantages of reactive programming; so many in fact, that reactive programming appears to be offered as some sort of panacea that will solve all of our problems forever. To me it seems that most of the alleged advantages of reactive programming as listed in that manifesto are either false, or non-sequiturs, so despite what the manifesto says, I posit that the sole purpose of existence of reactive programming is performance, in other words saving threads. Incidentally, this means that in any environment that offers virtual threads (for example, in Java starting from version 19) reactive programming is irrelevant. Change my mind. P.S. Unfortunately, when people become salespersons for a certain cause, they seem to be never content with just mentioning the one game-changing advantage of their product over the competition; they seem to always want to throw as much as possible at the customer, hoping to make them buy; so, they tend to include a torrent of inconsequential or even entirely fictitious advantages, which often has the effect of drowning the one important advantage in the noise. For example I have seen this with microservices, whose lists of advantages are often twenty items long; most of them are preposterous, and almost all of them are nothing but filler, because in fact microservices only have one game-changing advantage, which is scalability, or two if we want to also count resilience.
Mike Nakis wrote:
reactive programming appears to be offered as some sort of panacea that will solve all of our problems forever.
Of course. Not much of an evangelical if one has a new idea and then says 'but this solves almost nothing so you should almost never use it. And especially not when considering long term maintenance costs.'
Mike Nakis wrote:
become salespersons for a certain cause, they seem to be never content with just mentioning the one game-changing advantage of their product over the competition; they seem to always want to throw as much as possible at the customer,
Also of course. As a salesperson ones income is derived from that. Probably not a good idea for the owner of a McDonald's to tell you that Burger King burgers are cheaper and taste better. ------------------------------------------------- From the link
"Systems built as Reactive Systems are more flexible, loosely-coupled and scalable."
And with complexity that is significant. And that is by far the most significant factor is any large scale enterprise. No technology will fix that.
"The system responds in a timely manner if at all possible."
WTF? What system of any sort does not do that?
"The system stays responsive in the face of failure."
I doubt that is a given. If the architecture, design and implementation does not specifically do that then there is nothing a specific technology can do to fix that.
"that ensures loose coupling,"
Which also insures complexity.
Componentizing a system, any system using any methodology, means that the individual component (pick your granularity) is easier to understand but it adds to the complexity of understanding and diagnosing problems that impact the enterprise.
I just wish all of the difficult problems that I have worked on for the last 20 years could have been easily solved by looking at one component. The problems that were caused by a single component often could be diagnosed and fixed in less than a day.
"The largest systems in the world rely upon architectures based on these properties"
The largest systems in the world have been built over decades and have been based on many false starts and trial and error solutions to meet the specific business needs (and that is a very big plural) of the companies which hold those systems.
Small start ups cannot start with the a
-
The Reactive Manifesto ([https://www.reactivemanifesto.org/\](https://www.reactivemanifesto.org/)) is several paragraphs long and lists a large number of alleged characteristics and advantages of reactive programming; so many in fact, that reactive programming appears to be offered as some sort of panacea that will solve all of our problems forever. To me it seems that most of the alleged advantages of reactive programming as listed in that manifesto are either false, or non-sequiturs, so despite what the manifesto says, I posit that the sole purpose of existence of reactive programming is performance, in other words saving threads. Incidentally, this means that in any environment that offers virtual threads (for example, in Java starting from version 19) reactive programming is irrelevant. Change my mind. P.S. Unfortunately, when people become salespersons for a certain cause, they seem to be never content with just mentioning the one game-changing advantage of their product over the competition; they seem to always want to throw as much as possible at the customer, hoping to make them buy; so, they tend to include a torrent of inconsequential or even entirely fictitious advantages, which often has the effect of drowning the one important advantage in the noise. For example I have seen this with microservices, whose lists of advantages are often twenty items long; most of them are preposterous, and almost all of them are nothing but filler, because in fact microservices only have one game-changing advantage, which is scalability, or two if we want to also count resilience.
It's a raging tech sea. Many want anchors. If you want a quick ride to the bottom just beeline to the nearest lighthouse looking thing like this while pretending it's a silver bullet. Sell it to management as such too. It worked for agile! Even though that manifestos creators have basically since gone, "WTF, people? We weren't meaning to found a religion." Not to say I think agile is even "bad". But snake oil, silver bullets, and fascist purists sure tend to be.
-
It's a raging tech sea. Many want anchors. If you want a quick ride to the bottom just beeline to the nearest lighthouse looking thing like this while pretending it's a silver bullet. Sell it to management as such too. It worked for agile! Even though that manifestos creators have basically since gone, "WTF, people? We weren't meaning to found a religion." Not to say I think agile is even "bad". But snake oil, silver bullets, and fascist purists sure tend to be.
