TL;DR. In a world of high-speed computing where low latency is a goal and near real-time is the operative word, functional programming is capable of addressing those issues in an elegant and effective way. If you have only three programming languages to learn, the Big Three is all you need.
- Go (back-end)
- Scala (Big Data)
What is reactive programming (RP)?
To quote Andre Staltz, author of Cycle.js
Reactive programming is programming with data streams.
Why reactive programming?
Organisations working in disparate domains are independently discovering patterns for building software that look the same. These systems are more robust, more resilient, more flexible and better positioned to meet modern demands.
These changes are happening because application requirements have changed dramatically in recent years. Only a few years ago a large application had tens of servers, seconds of response time, hours of offline maintenance and gigabytes of data. Today applications are deployed on everything from mobile devices to cloud-based clusters running thousands of multi-core processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes. Today’s demands are simply not met by yesterday’s software architectures.
We believe that a coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems.
Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.
More on The Reactive Manifesto.
Why should I consider adopting RP?
Reactive Programming raises the level of abstraction of your code so you can focus on the interdependence of events that define the business logic, rather than having to constantly fiddle with a large amount of implementation details. Code in RP will likely be more concise.
The benefit is more evident in modern webapps and mobile apps that are highly interactive with a multitude of UI events related to data events. 10 years ago, interaction with web pages was basically about submitting a long form to the backend and performing simple rendering to the frontend. Apps have evolved to be more real-time: modifying a single form field can automatically trigger a save to the backend, “likes” to some content can be reflected in real time to other connected users, and so forth.
Apps nowadays have an abundancy of real-time events of every kind that enable a highly interactive experience to the user. We need tools for properly dealing with that, and Reactive Programming is an answer.
Why functional programming?
To quote the same author (read here),
I started developing Cycle.js after I took React for a spin and was disappointed with its API. I initially got really excited about the Virtual DOM concept in React, but could not understand why the API is built on OOP classes, state mutation, and imperative event handlers. There is a mismatch between React’s foundational ideas (reactive rendering and UI as pure function of state) and its implementation means (OOP, classes, imperative programming).
How about reactive programming in Go?
If you’re into so-called AP data systems, you’ve probably run into the term CRDTrecently. CRDTs are conflict-free replicated data types: data structures for distributed systems. The tl;dr on CRDTs is that by constraining your operations to only those which are associative, commutative, and idempotent, you sidestep a lot of the complexity in distributed programming. (See: ACID 2.0 and/or CALM theorem.) That, in turn, makes it straightforward to guarantee eventual consistency in the face of failure.
With a bit of thinking, we were able to map a fan-in-on-read stream product to a data model that could be implemented with a specific type of CRDT. We were then able to focus on performance, optimizing our reads without becoming overwhelmed by incidental complexity imposed by the consistency model.
The result of our work is Roshi, a distributed storage system for time-series events. It implements what we believe is a novel CRDT set type, closely resembling a LWW-element-set with inline garbage collection.
(Source: read here)
What’s the fuss with Big Data?
Read how Apache Spark, Scala, and Functional Programming made hard problems easy at Barclays.