In December 2016 I attended Scala eXchange 2016 – a traditional and quite interesting Scala conference that occurs every year in London, UK. I had the opportunity to attend it for the 4th time, and like every previous one, it was well worth the effort. In this post, we will take a pragmatic look at six things I learned during the conference. We won’t talk about the beer though – you should go there next time if you want in on this 😉
By the way, all talks are available on the conference web site linked above, so be sure to check it out. After you are done with this post, of course!
Number 1: Compilation time is still an issue, but it is being tackled
Compilation time was the subject of at least three talks during the event. The first of these was the keynote by Adriaan Moors, team lead of the compiler team at Lightbend, where he made it clear that they plan to spend half of their team efforts during 2017 improving the situation.
Next up was the controversial “Compilation time: a bigger hammer”, from Iulian Dragos and Mirko Dotta, from the recently created Triplequote company. They presented the tool they are creating for speeding up the compilation times, based on parallelization of compilation units. The whole topic was a bit controversial because the tool is a commercial effort. In one hand, the compiler should be faster by itself, without the support of external tools. On the other hand, the Triplequote developers are investing their own resources, so it is only fair that they can get something out of the effort.
Finally, there was the talk “Can scalac be 10x faster”, from Rory Graves. This one was very interesting and full of tips you can apply right now to your projects to improve their compilation times. We actually tried a couple of them in our project and managed to get some improvements. We specifically changed two things:
* replaced several wildcard imports (._) with specific imports
* split traits and class that were sharing the same .scala source file into separated files
The first change helped a lot in the total compilation time (after a clean). This is most likely due to the fact that with more specific imports, there are less places for the compiler to look for implicit conversions – and we do use implicit conversions quite a lot.
The second point was more useful in reducing the incremental compilation time – i.e., the chances of a given file to be invalidated and have to be recompiled were made smaller.
In terms of compilation time, there was a third point that we looked at briefly: macros. In this case, we wanted to start using a certain macro, to reduce code repetition, but gave up because it was increasing the compilation times quite a lot. For this kind of thing, the best tip we can give is to always pay attention to your build times when you decide to try new features. In our case, it seems that the extra compilation times were coming from a combination of the usage of macros and the usage of Shapeless in code generated by macro. Unfortunately, we never had time to properly isolate and fix the problem.
For all cases, the plan was to share some numbers, but since, like mentioned above, we didn’t have a properly isolated test scenario to share, the numbers were a bit biased. So I’ll just leave the message: do try those tips yourself and see if it changes something for your own projects.
Number 2: Scala compiler fork: a positive thing to have!
You probably already know that there is a group called Typelevel, and that they forked the Scala compiler. When this happened, there was some commotion in the community. Now, during Scala eXchange 2016 we had an interesting talk from Miles Sabin regarding this all, and what Typelevel had been up to, specially in 2016.
The biggest takeaway here is that the Typelevel scala compiler fork is a very positive thing, and has made a positive impact on the Scala community. For example, there are a couple of bug fixes for the Scala compiler that are available in the Typelevel version of the compiler. Moreover, you can use those fixes in the standard Scala compiler with a compiler plugin also made available by the team. Finally, such fixes are also being sent back to the Lightbend Scala compiler as Pull Requests, and some have been accepted!
One such case is the fix for the Scala issue 2712. It was fixed by the Typelevel guys and sent as a Pull Request to the standard compiler.
The fact that the above is possible confirms what Miles said during the presentation: Typelevel has an interesting rule: whatever improvements someone wants to make to the Typelevel Scala compiler, it must also be submitted as a PR to the standard compiler.
Finally, if you want to use the Typelevel Scala compiler in your projects, it is as simple as adding an sbt plugin to your build, as can be seen here.
Number 3: Shapeless is awesome and doesn’t have to be scary!
I’ll not dive too deep in this topic, but if you have ever heard of Shapeless and felt like it is too complex, you have to watch Dave’s talk. It was a very gentle introduction to the awesome framework that lets you do some great generic programming.
We use Shapeless in one of our libraries, Grafter, that offer a nice, generic, and “new old” way of dealing with constructor-based dependency injection, so this talk was useful in practice already.
One note before closing this topic: Shapeless is really useful, but it is intended more as a support to library authors than to application developers. So don’t watch the talk and start using it everywhere! That being said, knowing how it works will help you deal with such libraries, which includes the above mentioned Grafter, and the now famous Circe json framework, among others.
Number 4: The Future of Scala: it is moving forward and will keep doing so
Martin Odersky’s keynote talk, “From DOT to Dotty” was an interesting one for anybody that still has doubts about the future of the Scala language. Is it going to keep evolving?
Dotty is the future Scala. The interesting thing here is that this doesn’t mean it will replace Scala, at least not in the short or even medium term, but instead that it is a place where innovation can be tried out and really happen without too many restrictions, before they are implemented in the Scala language itself, where the stakes are way higher. Quoting directly from Martin’s keynote: “The plan is that Dotty should support future iterations of the Scala programming language”.
Dotty might one day become Scala 3, but this is not yet something that is written in stone – right now, some features that work well in Dotty are actually being backported to scalac – confirming Martin’s words again, when he said that Dotty is there to “support the next iteration of Scala”.
The diagram below, extracted directly from Martin’s talk, show the current planned roadmap – obviously highly subject to change:
A nice feature example, still to come in the (hopefully) near future, is typesafe equality. This is being implemented in Dotty but, right now, you have to use a library like cats or scalaz to get this functionality in the Scala language itself. But in the future, this will most likely be part of the standard Scala language.
Number 5: Zalando growing the Scala community
This is a bit self-served, but it is nice to know that Zalando as a company is growing in the Scala community. In Scala eXchange for example, we were present with six developers, from which two had talks being presented at the conference. The first one was by Joachim, who spoke about Akka Streams, and the second was Eric, with a talk about Practical Eff. Our participants also represented two different locations: four of them came from the office in Berlin, and two came from the Dublin office.
Number 6: Scala is OpenSource. And needs us all
Let us close this post with a call to action, mirroring the message from Heather Miller’s keynote. This call to action could be summarized in a single sentence, quoted directly from Heather’s talk: “we don’t want your money, we want your PRs”.
Scala is Open Source and lives, grows and evolves with help from the community. Its future is not tied to Lightbend’s hands, and to that end they have even created the Scala Center, which is an independent, not-for-profit organization focused on the future of Scala, community participation and the likes.
In the context of community initiatives, a lot was said about the SIP process and its improvements. This is another point where Scala seems promising for the future. Other than that, they are also trying to move to a more friendly platform for community discussions, other than mailing lists, in the form of a Discuss forum which can be seen here: contributors.scala-lang.org – modern and pretty 🙂
In the end, all of these initiatives aren’t appearing out of thin air. One source of information that she referenced was the book “Social Architecture” (https://www.gitbook.com/book/hintjens/social-architecture/details) – already added to my to-read list.
So, in summary: Scala is still hot, and will be hot for a long time to come! And when this time passes, there will come Dotty!