Promise of a Better Future

Promise of a Better Future

Slides from my talk at XConf Manchester, 2015.

C0d05079573ef8373cd044f0d6b14b03?s=128

Rahul Goma Phulore

July 09, 2015
Tweet

Transcript

  1. Promise of a Better Future Rahul Goma Phulore (@missingfaktor) XConf

    Manchester, 2015.07.09
  2. About me • Ex-ThoughtWorker (Pune, India) • Backend Engineer at

    SoundCloud (Berlin, Germany) • Functional programming practitioner since 
 5+ years
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. #1 No Concurrency

  8. CODE

  9. ✴ Pros ✴ Simple code ✴ Cons ✴ No concurrency

    :(
  10. #2 Java style futures

  11. CODE

  12. ✴ Pros ✴ Some concurrency ✴ Cons ✴ …still not

    nearly enough ✴ Doesn’t scale easily for more complex cases
  13. #2 Callbacks

  14. CODE

  15. ✴ 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.
  16. #3 "Functional" futures

  17. CODE

  18. ✴ 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!
  19. Callbacks vs functional futures

  20. https://goo.gl/CSkVZI

  21. "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."
  22. // Plain old blocking API readFile :: String -> (Buffer

    | Error) // Callback-based API readFile :: String -> (Error -> Buffer -> ()) -> () // Future-based API readFile :: String -> Future (Buffer | Error) Types
  23. // 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
  24. 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.
  25. Thank You! ☺