Foreword

This book, Rx.NET in Action, does a great job in explaining the details and background that .NET developers need to effectively use Rx. In particular, it explains how to connect the plethora of asynchronous types in .NET to Rx observables, and how to deal with errors, resource allocation, and last but not least, concurrency.

Since its inception, the .NET Framework has emphasized the importance of asynchronous execution and nonblocking I/O. Through delegates, the .NET Framework has emphasized higher-order functional programming from the beginning, and by automatically defining the BeginInvoke and EndInvoke methods on delegates, developers may call any method asynchronously.

But the BeginInvoke/EndInvoke pattern for asynchronous operations is tedious and verbose, because it requires converting your code into continuation-passing style. As an alternative, the .NET Framework introduced the event-based asynchronous pattern that uses the built-in support of .NET for events and event handlers. Although the event-based pattern was a big step forward compared to asynchronous delegates, more opportunities remained to streamline the development experience.

For synchronous streams of values, modeled by the standard interfaces of Enumerable/IEnumerator, the LINQ standard query operators provide a beautiful and elegant algebra for processing streams in a high-level and declarative manner. Wouldn’t it be nice if we could use the fact that events are conceptually also streams of values and hence provide a similar LINQ-based programming model for events?

Another disadvantage of using events for asynchronous calls is that this ignores the fact that unlike most other events, such as mouse clicks, the events wired up to asynchronous operations produce at most one value. Wouldn’t it be nice if we could use the fact that asynchronous methods return only a single value and hence provide a similar imperative programming model that supports regular control-flow-like conditionals, loops, and exception handling for asynchronous methods?

As it turns out, the answer to both questions is a resounding yes! By using the mathematical trick of equalization, we can mechanically convert the IEnumerable/IEnumerator interfaces for synchronous pull-based streams into the monadic IObservable/IObserver interfaces for asynchronous push-based streams. The async/await syntax in C# and Visual Basic allows developers to use regular imperative syntax to write both synchronous and asynchronous methods, and the LINQ query comprehensions allow developers to write queries over both synchronous and asynchronous data streams

This is the heart of Rx. Many languages outside the .NET world have now adopted the magic square of one/many × sync/async, making developers happy and productive no matter what language they’re using.

If you’re a .NET developer, you’ll want to keep a copy of this book handy to put Rx.NET into action!

—ERIK MEIJER

INVENTOR OF RX, FOUNDER OF APPLIED DUALITY