Reactive Programming: hype or truth?

Nov 22nd, 2013 By Pere Villega

Let’s leave the keyboards and code aside for a moment, and let’s talk about the current state of art in programming.

As developers, we tend to like technology and novelty, sometimes making the mistake of putting them before the business needs. Unfortunate, as business challenges can be more fun than hacking your Raspberry Pi, but I digress. The downside is that, quite often, we hype some new (or not so new) tool/language/thing into stardom and then drop it at the same speed while pursuing the next novelty we see around.

If you are keeping with technology news, you may have noticed a new word creeping around. Reactive. You have the Reactive Manifesto. There is a course in Reactive Programming. Indeed, it is all over the place.

And so, the question arises: is reactive programming a buzzword doomed to die or, quite the opposite, it is a new way of working with a potential impact similar to the Agile Manifesto?

I personally believe that this isn’t hype, that reactive programming is here to stay. Let me try to justify it.

What’s reactive programming?

First of all, we should clarify what do we mean by reactive programming. The aforementioned Reactive Manifesto gives a bit more detail on the matter, but it all boils down to 4 properties that the signers of the manifesto want software to have:

• Event-driven
• Scalable
• Resilient
• Responsive

As you can see, quite a generic definition that includes properties we all want in web-based apps. Event-driven is nothing new, servers like Nginx used this to solve the C10K problem. Scalability and Resilience is something any software developer of any decent sized application wants to achieve. And we already know that Responsiveness is money.

But, you may ask, if there is nothing new in this concept why has it become so popular recently?

Benefits of reactive

The answer to that question comes, as with many things, with context. We can’t deny that we are in a field that evolves extremely fast, just compare the technologies used on the web 10 years ago and now (hint: Gmail was released in April 2004 and it was revolutionary because it used…Ajax).

What is the current context in the web? Well, there are some interesting trends:

• mobile web: smartphones and tablets are becoming the main tools for browsing the web
• increase of users: the percentage of the population using internet has increased. A lot. Which means that a popular website manages one or two orders of magnitude more users than in 2000.
• user expectations: the fact that such a big percentage of the population uses the web has a downside for us, developers: few of them are early adopters which accept bugs as part of the deal. Users want a speed, quality, and for free (if possible).
• PaaS: servers are cheap. Extremely cheap. Amazon, Heroku, DigitalOcean… you can deploy a new web server in minutes, at a cost of cents per hour. But due to the nature of the services they offer, you are forced to break your application into more components, which means more potential points of failure while systems talk between them.

I could add more, but these are enough to show that the context has changed a lot, and it keeps changing. And this is where reactive programming ties in by defining properties that, in the past, were desirable but not critical. With the evolution of the web in the recent years, these properties have now become basic for any decent sized application.

For example, the emergence of PaaS and the reliance on remote calls via RESTful endpoints means that your code will be interacting with multiple components, any of which may fail. If your software is blocking (not event-driven) and synchronous, you are in for a nightmare made of exception handling code, low performance due to latency and thread locking, and unreliable code.

The natural solution to this issue is to go asynchronous and event driven, which in turn improves the scalability and resilience of the application by making it easier to handle errors and latency. That is, the solution is to go reactive.

Reactive and Typesafe

There is an elephant in the room that has to be discussed. Most of the push for Reactive Programming comes from Typesafe, the company behind Scala. They want it to succeed and they would benefit from that, for sure. But can we reduce Reactive Programming to mere economic interest, a PR stunt by a tech company?

Is my personal opinion that it would be foolish to do so. As much as they have an economic interest on it, the manifesto Typesafe sponsored is not focussing on any technology in particular. It is not a Scala manifesto, forcing people to use their tools through FUD.

The manifesto, and the concepts behind reactive programming, focus on architectural principles. Some desirable properties are defined and justified, and these are properties that any professional application needs to have. It’s not just a matter of technology, but in many cases of survival: a slow, non-resilient application will not keep its users for long.

You have working alternatives out there. Like it or hate it, but Python (via Tornado), Node.js and other frameworks can give you a reactive environment. The key here is not the tool used, but the architectural concepts behind.

So, yes, Typesafe has an economic interest. And they could have tried to push their own products. But instead they try to push a generic way of working, of good practices, that can benefit you whatever tools you use. This is not a matter of Akka vs other frameworks, it’s a matter of doing good software.

I hope that I’ve given you enough arguments to justify that Reactive Programming is not a fad, and that you should invest on learning more about it. Hype or truth? The discussion is open, feel free to join :)

Originally published at www.gumtree.com on November 22, 2013.