Why Reactive?

Chapter 2. Reactive on the Application Level

The assignment statement is the von Neumann bottleneck of programming languages and keeps us thinking in word-at-a-time terms in much the same way the computer’s bottleneck does.¹

John Backus

As the first step toward building Reactive Systems, let’s look at how to apply these principles within a single application. Many of the principles already apply on the local (application) level of a system, and composing a system from reactive building blocks from the bottom up will make it simple to then expand the same ideas into a full-blown distributed system.

First we’ll need to correct a common misunderstanding that arose when two distinct communities used the word “reactive,” before they recently started to agree about its usage. On one hand, the industry, and especially the ops world, has for a long time been referring to systems which can heal in the face of failure or scale out in the face or increased/decreased traffic as “Reactive Systems.” This is also the core concept of the Reactive Manifesto. On the other hand, in the academic world, the word “reactive” has been in use since the term “functional reactive programming” (FRP), or more specifically “functional reactive activation,”² was created. The term was introduced in 1997 in Haskell and later Elm, .NET (where the term “Reactive Extensions” became known), and other languages. That technique indeed is very useful for Reactive Systems; however, it is nowadays also being misinterpreted ...