Scala.io 2018
In the end of October 2018, in Lyon, the Scala.io conference took place. I was there and in this article are sumed up my notes and memories from this event. It is not an easy task to sumarize every presentation I went to, so instead of trying to do this, I will just give some of my highlights
Day 0: workshops
In order, Scala.io start for the first time with workshops. Unfortunately I did not register on time, so I was only there to chat with people.
Day 1
Martin Odersky's keynote
The day opens with a keynote by Martin Odersky, the father of Scala. After presenting the roadmap for the 1.5 year to come and the path to Scala 3, he took some time to introduce TASTY, the format to represent a Scala program. The keynote was interesting as it showed the path and approached which will make Scala 3.
I found the talk quite encouraging for the future and it looks like the community will try to avoid the Python2/3 situation and I think, will succeed in that. More on the feature side, news are good, as Dotty (Scala 3) is coming with simplifications and useful features for type level programming.
1001 styles of Scala
I decided not to dive into a very technical talk and I went to see Jean Helou for a talk called "1001 styles (de Scala)". In his talk based upon real stories, he highlighted how we have several styles of code. Starting from the original debate spaces vs tabs, to the global culture of a Scala team and the amount of FP to put in a project. In between, some interesting reflections about tribes, individual culture, company culture, and team common consensus.
This talk, and the questions that followed, really touched the human complexity of a software project. One thing that stroke me in particular is the realization of the path done while learning FP : my code style evolved, making possibly new comers feel awkward about some pieces of code. About this styling issue, I had a chance to talk with Jean at the community party and he made me realize that Java also went through this kind of different styles : from Java 1.4 where singleton were the norm to Java 1.5 and generics and now, to a new style with lambdas since Java 8 (and it continues with more type inference, and so on and so on,...).
More directly related to Scala, the talk mentioned tools to help teams in committing to a style guide, like scalafmt.
Algebraic effects
It is with no surprises that many talks were related to effects this year, given the whole activity on ZIO, cats-effect,... and on related topics like tagless final. So, I when to see Xavier Van de Woestyne for an introduction on effects systems and algebraic effects.
The speaker praises OCaml a lot, and after a short introduction, shows how we came up with two interpretations of monads :
- the direct style by Moggi
- the indirect style by Wadler
I am far from an expert in this field, but I understood some duality. While Haskell went on Continuations and the IO monad, OCaml is slowly drifting towards an effect system.
If I understood correctly, the goal is to provide honesty in function signature to indicate effects in it (and avoid them to be side-effects). The concepts involves a (syntactical) way to mark a function as effectful and effect handlers.
Many questions in the audience raised the subject of the composability of the effects, but as I am not sure I will just leave here the Ocaml+effects tutorial.
As a side note, it was nice to also hear about non-scala things.
Function composition
After lunch break, I came to support my fellow from Toulouse, Didier Plaindoux for his talk about function composition in the Traverse room. Like always with Didier and this kind of topic, you have to be ready to learn or re-learn things. This session was indeed right in this line. Despite Didier saying that the talk will be made in a "with the fingers" mode and not with a "theorical approach", the talk relied heavily on the substitution principles we apply when doing basic arithmetic. There could be a lot to say about this presentation, and in fact, it should be completely written to grasp everything ! Yet, for this article I need to pick just a few elements.
The first one is the equivalence between this pretty common encoding of functor:
trait Functor[F[_]]{
def map[A, B](fa: F[A])(f: A => B): F[B]
}
And this one:
trait Functor[F[_]]{
def map[A, B](f: A => B): F[A] => F[B]
}
Basically what is said is that : given a type A (any type) and a type constructor F, if we have a function from type A to a type B (any type), then using the type constructor we can define a map function which gives a function from F applied to A to F applied to B. The common former encoding is data centric as Didier says whilst the latter is function centric. Then going on and on with this substitution principle and we arrive to Kleisli by the end of the talk. The focus made on the second notation highlight the composition capabilities made by higher order function support in languages.
This talk is important because it reminds us constantly why equational is an essential property and why pure functions composition is fondamental.
The slides are here by the way ! And to go further, the book based on Bartosz Milewski's blog will do.
Cats IO
I decided to stay in the Traverse room to hear Gabriel Volpe talking about Cats IO. IO is a pretty hot topic this year in the community and it was a good opportunity to hear about it with a contributor to the cats-effects project.
The presentation starts with a good reminder of what referential transparency means, as stated by the famous example of Future (from the standard library) which breaks it.
val expr = Future(println("ScalaIO")
(expr, expr)
// is not equivalent to
(Future(println("ScalaIO"), Future(println("ScalaIO"))
Using Cats IO, it is pretty different :
val expr1 = IO(println("ScalaIO"))
(expr1, expr1)
// is equivalent to
(IO(println("ScalaIO")),IO(println("ScalaIO")))
The former version using Future outputs to the console and the latter using IO just describes the intention of performing a side effect. With this monad, the goal is to defer the execution at the end of the world.
Using IO, a program become a value. And we can compose values, to compose larger programs. Gabriel showcases how we can use IO in complex situations, like racing different tasks with different fail strategies using different combinators. As the talk goes on, we browse examples where we progressively improve the design by decoupling the effect part from the logic using the tagless final encoding. The basic idea is to not commit to the IO type too early and leave the possibility to use State in the tests for instance. The talk ends with real life examples. Go for the slides and the code .
Spotify Magnolia / Coders
Julien Tournay was back in France to give us some insider stories from Spotify. After a very short introduction on the big data pipeline at Spotify, he introduces one of the first issue he had to face with his team: the poor land of Java serialization when working on Scio which is the Scala API for Apache Beam, inspired by Spark and designed to run on Google Cloud Dataflow. Julien shows benchmarks showing how Java Serialization is bad (no surprises here), so the team in charge at Spotify used Kryo instead to serialize. But Kryo comes with its own issues, like runtime reflection (it's a Java library, remember). This runtime reflection aspects is particularly costly when the issues occurs in jobs which can take hours to complete, wasting time and money. Then Julien explains how, using Magnolia to automatically derive the Coders (the typeclass in charge of Serialization/Deserialization), and the low level API, the team in charge at Spotify was able to lift this serialization issue to compile time. But this does not solve the problem of a large code base still using the legacy way to do serialization/deserialization. So Julien used scalafix to modify the legacy calls with an automated migration ! But that wasn't enough in some cases so he showed how the fallback strategy is to rely on the legacy when instances could not be derived properly by Magnolia. All this with warnings at compile time, and a clear message, so that a manual fix could be easily done.
This talk was a proof of what we can achieve with Scala. And this is impressive. Such a change in a Java codebase would have been a nightmare and a manual boring thing to do for a developer. Instead, this approach leverages the brain in every developer.
Cat Theory (parametric)
By the end of the day, I was ready to get my mind blown (again ?) with a last talk on Category Theory. The talk, given by Greg Pfeil, almost took off where Didier stopped just a few hours earlier. Quite perfect to end the day !
During this talk, we abstract to the maximum defining in Scala the primitive of the Category Theory. Starting from the same rewrite of Functor & Kleisli as Didier did, we then try to write what a category is. It is just objects and arrows between them. And with just that we use the simple substitution model to build up abstractions. The presentation is readable here.
While the subject of this talk is very abstract and sounds more Math than Code, it is important because it shows how we can abstract. The power of abstraction is to connect, recognize patterns in domains which, taken individually, would remain specifics. As such, we see how Category Theory really is fundamental. This talk was also a good opportunity to know where to go next in the path to learning Category Theory.
Day 2
De Goes Keynote
I was looking forward to hearing this keynote. John De Goes is the father of ZIO, and the Bifunctor IO. His talk is an exhortation for us, Scala developers to write beautiful Scala. After an introductory speech with a Genesis metaphor, where the Serpent is here to trick Adam into crazy inheritance trees instead of focusing on the power of composition. Then he describes how we can deal with the external world while remaining pure, using ZIO. As Gabriel did it the day before, John shows examples of the beauty of the ZIO approach. In the end, he gives a sneak peek of what is coming next, Scalaz Streams.
It is always interesting to see De Goes on stage, as he is a good speaker and he has this ability to explain complex things with simplicity. At the end of the talk, he asked some questions like "who don't know what a functor is ?" and those who did not know were invited to climb on stage. In the end, he gave copies of Sam Halliday so that the "beginners in FP" could improve their knowledge. He also invited all of us to spread the knowledge, once acquired. This was a nice moment of community care.
Some Haskell
Celine Louvet, who is going to DevFestToulouse next week (November 8th), by the way (go people of my town, go see her !), gave an interesting and honest feedback on her beginning and present with Haskell. The main point, in my opinion is that, in order to successfully write applications in Haskell, she had to put her ego, her pride, her existing knowledge of other paradigms aside. I think that it was a good talk for those who are afraid to jump on the FP train. Despite a steep first step, she never gave up, found help easily and I think I am not mistaking if I say that she asks us to join her along this Haskell trip.
HTTP client automatic derivation.
This talk was awesome. Using heavy type level programming, Paul Heymann shows a practical use case of these techniques, and it is bluffing.
Although it was hard for me to grasp everything, it showed again the typelevel power of Scala. And it showcases things, like Witnesswhich may appear in Scala 3. The entire story is here and even if it is almost impossible for me to write a summary here, I encourage you to take some time, read the blog entry, and meditate on this !
See you next year
I did not list all the talks I went to. Some sessions on Scala tooling (like the ending keynote), or on GraphQL are worth mentioning. Overall, Scala.io is a simple conference, with (very) high quality talks. Speakers are not there to sell solutions or frameworks, they are mainly there to share and spread knowledge. Add to this a great community party to relax and meet people, and it is a perfect blend !
What's next ? Well, I have tons of things to read, try and learn. And for sure, I will be at Scala.io 2019 !
*Edit on Novembrer 9th : I forgot to mention the staff, volonteers and organizers. The spirit of Scala.io is what it is thanks to them. Great job ! *