Promise of a Better Future

Slides from my talk at XConf Manchester, 2015.

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! ☺