Scalasphere 2017 by Jędrzej Nowowiejski & Sebastian Szyller

Beginning of March in Cracow brought us the 2nd edition of this conference. Scalasphere could be categorized as quite unusual as it's focused not on academic discussions, frameworks or languages themselves but rather on tooling. Tooling, which usually is not perceived as valuable itself (that's a shame). Fortunately, we know the truth, the truth that these 'secret friends' help us be effective and successful on a daily basis. All developers using such complex and rich languages as Scala will probably agree that without proper automated help they would spent significantly more time doing things that seem trivial in other languages. Frankly, it's amazing that this conference gathered around 200 people that are not only interested in this kind of software but also eager to spend their free time on improving these tools. Congratulations to organizers and kudos to everyone that participated! Let's start with a few words about the venue. Beautiful view on Wisła river and real palms growing inside a building were so impressive and made us curious what would come next. Big lecture-rooms, interesting sponsors’ stands and nice coffee service and we were finally prepared to absorb knowledge. To write about all talks that we attended would take too much space and time to read about, especially that all of them are available on the conference website/youtube (scalasphere.org/). Therefore, in this review we decided to focus on "the things", sthe things that we as participants are taking home (of course except sponsor's gifts;)). Bear in mind that it's very opinionated and does not cover everything that was presented at ScalaSphere, so we strongly recommend to check talks online by yourself.

1. Scala compiler is slow, but this is not a curse. We believe that many new Scala coders are not aware that the way they are writing apps may radically change the compilation time. The great example are implicits. They are a really powerful tool that may be applied in many different contexts. However as one of the comics says: "With Great Power Comes Great Responsibility" and that's really true when it comes to implicits. Compiler is doing many things for you and one of them is resolution of implicits. It has to take time, if you have many of them in scope and you don't want to help compiler hunt them. Advice: always think about their scope, it will save a lot of CPU time. But that's not all that you can do to decrease compile time:)

   Secondly, there was a common theme that was present during different talks and that’s speed of the type parser. We all know that compilation consists of different subtasks like indexing or bytecode generation and the abovementioned type parsing is also one of such steps. Long story short, the role of the type parser is to analyse all types in the code and generate a syntax tree that can be later used to validate the type-safety of the code and then make the bytecode from it. It’s worth pointing out that this task is crucial because at the bytecode level JVM does not handle any types explicitly, but only implicitly through static type inference. This is particularly important in case of Scala as its generics are a lot more powerful than the Java counterparts and more widely used, when it comes to mainstream development. As a result, many people tried to come up with a solution that would speed up the overall compilation time e.g. via caching partial compilation results (Krzysztof Romanowski @RomanowskiKr from Virtus Lab), using distributed version of the Scalac compiler (Hydra compiler from @triple_quote - you can see that they already helped a lot Zalando to make their builds over a 3x faster) or trying to reinvent the type parser itself (Scala.meta). Let’s focus on the last case. It should be noted that at the moment there are three official type parsers in Scala - in Scalac (used in sbt, comes with the Scala distribution), in dotty-compiler (next version of Scalac that will come with Dotty i.e. Scala version 3.0) and in IntelliJ’s (or rather IntelliJ Scala plugin’s) implementation of the Scala compiler and presentation compiler. They do not differ substantially but unfortunately in all cases the type parsing step is quite slow. This is where Scala.meta comes to the rescue. This library is supposed to work on the meta-level of the language and fill the role of the Scala’s reflection API as well as replace or at least aid the procedure of the building the abstract syntax tree. But what is abstract syntax tree? Every language has types, keywords and syntax features that define how the code is written. AST is a tree representation of all those constructs and in the end it corresponds to a semantically consistent structure that represents our code. So far, Scala.meta is in quite early stages but it already shows promising results. Furthermore, rumour has it that JetBrains is planning to invest time in Scala.meta and rewrite its Scala plugin using that library. The only thing that is really needed are contributors so feel free to have a look at the git repository and drop a pull request or two!

2. Find new usage of already existing simple language mechanisms. That point was inspired by Jon Pretty @propensive talk about contextual. Library that allows you to use String interpolation to validate your inputs. It already supports: some bash command’s syntax, emails, jsons, xml and some more. You can also use it to add your own implementations and that sounds great. To be honest we were sceptical about that as interpolators are applied during compilation phase, so it will work only for strings that you as developer put directly in the codebase. However (thanks to Kamil Owczarek) we found a way to use it in our daily work, we can use it when we want to write some tests with jsons and validate their content (at least on the json specification correctness level). Also bush support sounds promising and may be a true friend, which helps you to avoid unexpected problems in Production runtime as again it works during compilation, so you will know that you made a mistake, before you will try to run it! It took our some time, but we realized that the real greatness, which stands behind it, is to move runtime errors to compilation phase and solve them there. Genius! That conept is amazing. Now we are thinking, if we can’t use some other similar concepts to move further - really interesting homework :)
   
3. Building community is really important and Scala have great one. After conference organizers invited everyone to join hackathon. What's more during this event people made some PRs for scalafmt etc. (Ólafur Páll Geirsson about hackathon). We think that's cool, that we are not only using, but also actively trying to help develop tools.

To sum up conference was really nice, great after party and comfortable venue. There was also chance to participate in sister ReactSphere that was taking part at the first day of ScalaSphere (where Jan Pustelnik and Kamil Owczarek from Lodz have their talk), but we were too interested in tooling and missed almost all talks there. Can we recommend this conference to other people - yes and no at the same time. If you didn't work with Scala, we have a mixed feelling if you should go there. You would see that Scala compiler is slow and people work on improving it, developing tools to help you with refactoring, debugging and dependency management, but this is still WIP. That may discourage you from trying to work with it. That's a mistake! You can do many things in this language (for sure more than in Java), but you have to be aware that Scala compiler is doing many things for you, just to let you reduce time of writing code and that comes with price. If you want to spend less time coding, compiler have to do more things for you and that's the tradeoff. You have to choose wisely what you prefer: lower compilation time or flexibility and powerful type system. From the other hand we can recommend this conference to all people who already worked with Scala. It was a real pleasure to be 'an ambassadors' of JUG Łódź at this conference (thanks again for tickets JUG!).

Jędrzej Nowowiejski & Sebastian Szyller