As you might have guessed by the title, most of the talks were about handling side effects 😉 We had the chance to watch excellent presentations on the subject: the IO Monad, the Eff Monad, Tasks, and cats-effects among others.
Since all the talks were filmed, making a detailed review of each talk would not add much value. Instead we are going to give you key points of our prefered talks (so many to choose from!!). If you were intrigued by these talks and want to go into the specifics, watch out for the videos to be uploaded on Scala.io’s Youtube channel in a couple of weeks.
Scala.io v4 started with the speaker dinner (our colleagues Daniel Krzywicki and Étienne Vallette d’Osia had the opportunity to be speakers, lucky them ;-)). They were served an excellent dinner with terroir products and wonderful wine… in a French Château.
“The making of an IO” by Daniel Spiewak
Daniel Spiewak explained (with a lot of energy) the problems of Scala’s Future and its current alternatives (like traditionals IO monads, Scalaz 7 Tasks and others). He showed that many libraries were neither efficient nor safe to use.
One of the first concerns was related to Futures and its relationship with Promises. According to him, it makes reasoning about code more complex. His talk also discusses the known problem of the eager approach and how it could lead to unexpected behaviours.
He also gave some remarks on the popular Scalaz 7’s Task. One of the problems he brought into light was the case of a Task that has just acquired a resource: it can be stopped without providing any way to free the resource. This resource management issue makes every call asynchronous, which in turn causes all code using Task to be slower than expected. After all, if my code should be asynchronous (thus I’m forced to use Future or IO) but isn’t in most cases, why should I have to pay the price of asynchronous execution every time?
Finally, he introduced the IO monad present in cats-effect as an alternative to previous implementations, he explained the difference as follows:
It is effective for both synchronous and asynchronous code
It does not provide unsafe methods
It can be used as a common interface for other implementations as well
An important point is that cats-effect doesn’t aim to handle the parallelism by itself. Therefore, it can be used along libraries like fs2 for such needs.
“The Design of Scalaz 8 Effect System” by John A. De Goes
John A. De Goes presented the Scalaz 8’s response of the Scalaz 7 Task’s issues reported by Daniel Spiewak: scalaz-effect. It may not be fully production-ready until mid-2018.
This new version provides its own implementation of the IO monad, scalaz-effect. It should be both quite different and yet compatible with the cats-effect’s version.
A particularity of scalaz-effect is that it also provides a way to deal with parallelism, by introducing an implementation of fibers (non-pre-emptive green threads). It then builds an IO mechanism on top of them (the pre-emption can be done at every map/flatMap call).
It is then possible to fork an IO (by creating a new fiber), to join existing IOs, to race IOs (returns only the first IO to respond, but give a way to deal with the loser fiber), and (the part which really impressed me) to be sure every fibers that might have been created in a block are either done or cancelled.
Finally, he presented some tools using IOs, like MVar (a monadic immutable AtomicRef version) which can be used to build higher level tools like channels. In a word, we may be able to code à la Go (think goroutines and channels) but in Scala.
The code has just been made publicly available (in a pull request), we can’t wait to play with it and see what can be done with it!
“Survivre à un monde débordant d’effets” (How to survive in a World full of side effects) by Benoit LeMoine
Benoit Lemoine gave us a recap on function purity and totality, but also on their contraries: exceptions, mutability, IO and Unit. He explained the principles of Type-Driven Development through an example of a Vending Machine.
Benoit explored the advantages and potential problems of several monads including Try, Either, State (cat’s implementation) to end up with cats-effect. This topic led us to Monad Transformers.
He showed us how they rapidly reached their limits when there are several different effects to handle.
Obviously, we then discussed the Eff Monad (here you have an implementation for cats) and how it is intended to solve the aforementioned problems.
“Composable Event Sourcing with Monads” by Daniel Krzywicki and Étienne Vallette d’Osia
Daniel and Étienne wanted to help composing event-sourcing code by using a functional approach. They started by explaining the concept and advantages of event-sourcing, and then introduced a very basic model that got improved during the talk.
The problem to solve was: how to allow the composition of code that handle events and be able to send those events at the end of the processing. Assuming that it is possible to store these events atomically, the concern was to write the code which generates them.
They first showed a handmade version and pointed out its limitations (in both simplicity and safety), then iterated to improve this code using structures from Category Theory.
We were really happy to see that many people came to see our colleague’s talk although Bartosz Milewski was talking Category Theory at the same time!
“Timeseries Jobs scheduling at Criteo with Cuttle” by Guillaume Bort
Guillaume Bort presented the problematic of an analytics (think Big Data) scheduler. This is the kind of scheduler that needs to:
Ensure that an hourly job is called every hour. Even when the server has been down for some hours, it has to catch up on the missing hours
Handle the dependencies among jobs with different time ranges (e.g. an hourly job waiting for a daily one)
Handle the redo of a job for a specific period (if we think there was a data corruption between 2am and 5am, we need to be able to redo the computations for this period),
Trace when a job has been done, especially for a manual redo
He then introduced Cuttle, an embedded job scheduler. It handles all the problems described before and is embedded in the application, so there can be multiple autonomous instances (more simple to reason about) but which still can communicate among themselves.
We liked the pragmatic approach of our former colleague, and we will keep this project in mind if we encounter problems which need this kind of job!
In the end, even though the high speed train taking us home hit a wild boar, we all shared our enthusiasm for Functional Programming with some other passionate developers from around the world. But most importantly we learned a lot!
Finally, we wanted to thank all members of the scala association who spent their days and sometime nights to organise this conference. We love Scala and will continue to support this great community. Thanks guys !
To scala.io 2018!!
Interested in Functional Programming?Join us