Over the past few years, web-applications have started to play an increasingly important role in our lives. We expect them to be always available and the data to be always fresh. This shift into the realm of real-time data processing is now transitioning to physical devices, and Gartner predicts that the Internet of Things will grow to an installed base of 26 billion units by 2020.
As reactive architectures gain in popularity, more and more developers find themselves faced with the challenge of "thinking reactive". To leave behind the well-known concepts of mutable, object-oriented, imperative and synchronous programming in favour of immutable, functional, declarative and asynchronous programming requires quite a mind shift and it isn't obvious to take the plunge.
In this talk we will explore three concepts from the world of functional programming that are at the core of building reactive applications: immutability, higher-order functions and manipulating immutable collections. We will first see how the "traditional" mutable, object-oriented approach of doing things can be problematic when it comes to multi-core programming, and then how to apply them to asynchronous systems.
3. Who is speaking?
• freelance software consultant based
in Vienna
• Vienna Scala User Group
• web, web, web
4. Who is speaking?
• freelance software consultant based in
Vienna
• Vienna Scala User Group
• web, web, web
• writing a book on reactive web-
applications
http://www.manning.com/
bernhardt
dotd051315au 50% discount
17. Why Reactive: summary
• distribution accross CPU cores
• distribution accross networked machines
• need tooling to work with this type of distribution
28. The problem with
locks / latches
• solution workaround for a broken
conceptual model
• huge coordination overhead! Even
more so when distributed
• hard to reason about
• performance hit
31. Immutable state -
why now?
• main memory is cheap!
• disk memory is cheap!
We can afford copies of past state
around in order to reduce
coordination efforts
32. Immutable state -
how?
case class Car(brand: String, position: Int)
val car = Car(brand = "DeLorean", position = 0)
val movedCar = car.copy(position = 10)
val movedCarLaterOn = car.copy(position = 30)
Working with different
version
"Snapshots" of reality
33. Immutable state -
how?
• clever immutable data structures,
e.g. Bitmapped Vector Trie 2
• do not copy data around - point to
unchanged data instead
• constant time for all operations
2
http://lampwww.epfl.ch/papers/idealhashtrees.pdf
34. Immutable all the
way down
• immutability changes everything 3
• programming languages
• databases: insert-only, event
stores
• SSD drives
3
http://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf
35. Immutability: summary
• we can afford to keep everything, with good performance
• reduces the headeache of coordination accross CPU cores
and networked nodes
• audit trail of changes for free
58. Functions
• portable and re-usable behaviour
• data changes, behaviour can be re-
used
• functions as data transformation
pipelines
59. Functions = data transformation
pipelines
val addresses = users.filter(_.age > 18)
.map(_.address)
.sortBy(_.city)
Build increasingly complex behaviour through a series
of transformations driven by composing functions