Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Promise of a Better Future

Promise of a Better Future

Slides from my talk at XConf Manchester, 2015.

Rahul Goma Phulore

July 09, 2015
Tweet

More Decks by Rahul Goma Phulore

Other Decks in Technology

Transcript

  1. About me • Ex-ThoughtWorker (Pune, India) • Backend Engineer at

    SoundCloud (Berlin, Germany) • Functional programming practitioner since 
 5+ years
  2. Thesis Concurrency is hard. Necessarily so. However our tools make

    it harder than it has to be. Promises and futures is a concurrency abstraction that cater to many common use cases for concurrency, and make writing correct and concurrent software easier.
  3. What are futures? • A proxy to a value that

    might be available at some point in time. • A value of type Future[Int] is a proxy to a value of type Int. • Some implementations separate promises and futures, some don’t.
  4. What are futures? • Futures are multiplexed onto threads. You

    can have hundreds of thousands of futures with just a handful of threads! • The thread pools are typically configured separately. • We do not block current thread while waiting for a result of another future.
  5. Running Example • Given a facebook page, grab likes for

    all the posts on that page. • If there is an error, log it and return an empty sequence.
  6. ✴ Pros ✴ Some concurrency ✴ Cons ✴ …still not

    nearly enough ✴ Doesn’t scale easily for more complex cases
  7. ✴ Pros ✴ Concurrency. Yay! ✴ Cons ✴ “Inverted” APIs

    ✴ Requires a lot of hand-coordination. Control flow needs to be dictated. ✴ Doesn’t scale easily for more complex cases. ✴ Error handling is complex.
  8. ✴ Pros ✴ Retains pretty much the same shape as

    the original non- concurrent code. ✴ Invisible, except when it shouldn't be. ✴ Computations expressed as data dependencies, rather than with complex control flow. ✴ Error handling is smooth. ✴ Scales easily. ✴ Cons ✴ … We'll come to that!
  9. "I hope to dismiss the misunderstanding that promises are about

    having cleaner syntax for callback-based async work. They are about modelling your problem in a fundamentally different way; they go deeper than syntax and actually change the way you solve problems at a semantic level."
  10. // Plain old blocking API readFile :: String -> (Buffer

    | Error) // Callback-based API readFile :: String -> (Error -> Buffer -> ()) -> () // Future-based API readFile :: String -> Future (Buffer | Error) Types
  11. // Plain old blocking code: (=) :: a -> (a

    -> b) -> b map :: Seq a -> (a -> b) -> Seq b tryCatch :: (() -> a) -> (() -> a) -> a filter :: Seq a -> (a -> Bool) -> Seq a // Future-based code: (<-) :: Future a -> (a -> Future b) -> Future b traverse :: Seq a -> (a -> Future b) -> Future (Seq b) recover :: Future a -> (() -> a) -> Future a filterF :: Seq a -> (a -> Future Bool) -> Future (Seq a) Types
  12. Still not a silver bullet • Interactions with thread-unsafe libraries.

    • ThreadLocal variables. • Complex co-ordination not very natural. • Simpler than other concurrency models, but still some cognitive cost. Could be better. • Not suitable for all sorts of concurrency scenarios.