In short, Reactive programming aims to make it possible to do more stuff with fewer threads. Ideally, one thread per core.
The thinking is that at any given instant of time, no matter how many threads you have in play, only one thread per core is actually active. And the management overhead of handling many threads outweighs the benefits of having multiple threads. So...if we have only one thread per core, then there's no need to swap out threads. This is achieved with a pattern called event-looping. I won't go into it here, but event looping makes sure that each of the threads is constantly busy handling many things, but no thread ever goes idle or is swapped out. And the result is: More stuff gets done with only a few threads.
Well, that's the goal...and it's certainly achievable without Reactive programming, but it would require the developer to be really really really good at thread management. Most developers I talk to will admit that concurrency is hard and that thread management isn't their strongest skill. Reactive programming is a programming paradigm, backed by a reactive platform such as Reactor, that keeps the details of event-looping out of the developer's mind, letting them focus on just achieving the one thing that they need to achieve as if it's the only thing being achieved (when in reality, it's just one of many things running through that event loop).
That's a poor explanation...it's hard to succinctly describe it without getting into examples and details...and I really wanted to draw a picture of an event loop. But hopefully that helps.
paul nisset wrote:
I'm a fan of your books.
In another post you mentioned there is new emphasis on Reactive Programming.
Is this an industry trend ? Why is it important?
Is this what Spring is now trying to encapsulate?