Promise of a Better Future Rahul Goma Phulore (@missingfaktor) XConf Manchester, 2015.07.09 

About me • Ex-ThoughtWorker (Pune, India) • Backend Engineer at SoundCloud (Berlin, Germany) • Functional programming practitioner since 
 5+ years 

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. 

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. 

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. 

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. 

#1 No Concurrency 

CODE 

✴ Pros ✴ Simple code ✴ Cons ✴ No concurrency :( 

#2 Java style futures 

CODE 

✴ Pros ✴ Some concurrency ✴ Cons ✴ …still not nearly enough ✴ Doesn’t scale easily for more complex cases 

#2 Callbacks 

CODE 

✴ 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. 

#3 "Functional" futures 

CODE 

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

Callbacks vs functional futures 

https://goo.gl/CSkVZI 

"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." 

// Plain old blocking API readFile :: String -> (Buffer | Error) // Callback-based API readFile :: String -> (Error -> Buffer -> ()) -> () // Future-based API readFile :: String -> Future (Buffer | Error) Types 

// 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 

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. 

Thank You! ☺