KotlinConf 2018 - Recap

On October 4th and 5th the 2nd Kotlin Conf took place. We were here to attend the conference, learning new Kotlin tricks, but above all, to feel the amazing Kotlin vibe. After a first edition in San Francisco, the Kotlin Conf set up this year in Amsterdam, in the beautiful Bars Van Beurlage venue (one of the conference room was even lit with stunning stained glasses).

Here is a recap of the talks that impressed us the most, classified by the main themes we identified during these two days

Kotlin as multi-platform language

One of Andrey Breslav’s main point of emphasis during the opening keynote was that Kotlin is not limited to Android development. More than 40% of attendees were indeed using Kotlin for backend development, and more than 30% for web development. As mobile developers, we were curious to find how others used Kotlin, in multiplatform projects and backend applications.

Ryan Harter gave a great talk and explained us how to begin Building Server Backends with Ktor. Ktor is an open source Kotlin server framework mainly developed by JetBrains. It uses a lot of the language’s loved features like extension functions, a type-safe builder to describe the application and is entirely based on coroutines. The Kotlin 1.3 release comes with Ktor 1.0 beta. We were amazed by how easy and intuitive it seemed to use the framework.

In Architecting a Kotlin JVM and JS multiplatform project, Felipe Lima gave an overview of the main multiplatform principles. The most important concept is the use of a shared module for all platforms. Felipe encouraged us to share as many code as possible between platforms, until platform specific APIs are needed. You can then bridge the common and platform specific modules with the expect/actual mechanism. However, we were a bit disappointed that he only told us about a project he did in his spare time, a NES emulator, and not a project he worked on at AirBnb. Given their past experience with React Native, we were eager to hear about what he had to say about their experience with dealing with multi-platform in a professional context. Plus, his personal project was not done yet, and he had yet to work on the JS side.

Multiplatform projects are still in an experimental state, meaning some breaking changes may occur when hitting 1.4 or later versions of Kotlin, but it’s one of our main point of attention, as we feel it will shape our work in the future. We’ll make sure to keep an eye on it.

“Unexpected” use cases of Kotlin

As mobile developers, we were impatient to discover some unexpected use cases of the Kotlin language that could differ from what we do on a daily basis. The Kotlin Conf 2018 filled our expectations by offering talks on some “unusual” topics (at least for us).

One was Paul Merlin’s talk Type-safe build logic with Gradle Kotlin DSL. In 2016, Gradle announced its will to add the possibility to write build scripts in Kotlin instead of Groovy. The goal is to take benefit from the statically typed characteristic of Kotlin to achieve faster builds, a better integration with the IDE and checks at “compile time” instead of run time. We made some attempts to use the Gradle Kotlin DSL since and we experienced many performance and IDE related issues. Therefore, we were impatient to see the improvements brought by 1.0-RC version. In his talk, Paul showed us step by step how to migrate an existing Groovy script to a Kotlin one. If the intention is praiseworthy, we think it would have been more relevant to show us how to write a script from scratch to put the light on Kotlin and not be in the “shadow” of Groovy. Moreover there was some unfortunate malfunction in the Kotlin script refactoring presented (the well-known “demo effect”) which slightly tarnished the demonstration. Another issue conceded by Paul is today’s Kotlin gradle script slowness compared with its Groovy version. To sum up, our opinion is that, even if promising, the Gradle Kotlin DSL is not mature enough to be used in our projects.

Another possible usage for Kotlin is the ability to perform some data science analysis thanks to a Kotlin stack. Indeed, in his talk Building Data Science Workflows with Kotlin, Holger Brandl demonstrated how he solved a Kaggle competition (the famous taxi fare prediction) thanks to a Kotlin stack. He started admitting that the Kotlin statically typed attribute was a disadvantage compared to the “classic” data science language, Python and R, when it comes to write some “quick” exploratory code. He used the following stack:

• Sparklin & KShell for data processing and interactive shell
• Krangl a data manipulation library developed by the speaker himself allowing data operations (including data import from various file format) thanks to a data scientist friendly api.
• Kravis, also developed by Holger, a wrapper around ggplot2 used to display graphical results
• Jupyter kotlin: a portage of the well known notebook commonly used for formatting data science experiments.

Even if most of these tools are in an early stage of their development and brought a slight “messy feeling” to us , it is really exciting to see that there is already, in Kotlin, a usable stack of tools to perform these kind of tasks.

Coroutines

When announcing Kotlin 1.3 features during the opening keynote, Andrey Breslav happily started with coroutines reaching 1.0. Meaning we can finally drop the experimental package from our imports. We’ve been using coroutines in production for some months now, and the experimental experience has been really easy to deal with. It fits with the mindset Breslav explained in his keynote: we do not want any legacy in the language code, but we want to have comfortable upgrades.

Besides the keynote, they were several talks on the subject. In Android Suspenders, Chris Banes went back explaining why the changes in the 0.26 version were needed: before that, launched coroutines were unscoped and it was really easy to leak them (that sadly happened to us). He then went ahead and explained how he used coroutines with the Architecture Components View Models.

In the ever longing question “RxJava vs Coroutines”, Banes joined the opinion of others (Christina Lee & Jake Wharton for example): If you only need Rx to do basic threading, coroutines will be simpler and better suited. If you want to do trickier things, Rx operators can be a daunting task to learn whereas there are fewer, more traditional operators that come with coroutines. Plus, it’s quite easy to write custom ones.

In order to represent things closer to Rx streams, we could use channels. But something that was discussed often, by C. Banes in his talk and C. Lee and J.Wharton during the ending panel, was the inability of channels to represent cold streams. For now, they are closer to Rx’s Subjects than Observables.

After those two days, everyone appeared really excited about coroutines hitting 1.0. And we were quite comforted on our position, that coroutines are well suited for our needs as Android developers.

Use Kotlin’s power to your benefit

One recurring topic was to use the language’s many features to gain readability, safety, and ease of development. It was inspiring to see what kind of issues developers faced, and how they used the same tool we’ve been using for more than a year now to solve them.

Romain Guy told us in Kotlin for graphics how he used the language to do 3D programming. That means that all he’s doing is … maths. In this case, functional programming works really well. We do not need to abstract maths with OOP, and all that’s needed are some top level functions, some operators overriding (for matrices and vectors for instance) and you’ve got yourself quite a readable, concise graphics code.

Christina Lee, in her talk Sealed Classes are great Representing State: the Kotlin Edition wanted to make us aware that types matter. The big takeaway is that usual types like Int or String are unbounded, and represent an infinity of values. You have to ask yourself: is it what I really want to represent? If not, a great way to bound your types and make an opinionated choice is to use Kotlin sealed classes. We’ve been using them to represent view models and errors / successful results for a while now and this talk comforted us in our vision of Kotlin as a language that enforces good programming practices. Romain Guy also mentioned some 1.3 features that will help have greater control over which types we use, with the incoming _UInt_s and inline classes.

From the opening keynote, one of the buzzwords of this Kotlin Conf was meta programming. If you’re wondering what it is, Amanda Hinchman gave a quick definition in her talk Kotlin: The Next Frontier for Modern (Meta)Programming: It’s a program that treats programs as data. It can read, analyse or transform other programs. Traditionally, languages like C++ use macros to tackle this, but the Kotlin team chose not to follow this path, and use annotation processing and compiler plugins instead. Amanda Hinchman explained how more traditional AOP (Aspect Oriented Programming) based on annotation processing, like in Java, is still a viable solution. But a more interesting one is to use Kotlin’s type-safe builders to create your own DSLs. On the other hand, Writing Your First Kotlin Compiler Plugin by Kevin Most was an advanced talk on the subject. You may have used a compiler plugin without knowing it if you’ve used the Kotlin Android extensions. They are similar to annotation processors, but instead of generating Kotlin or java code, they directly generate bytecode. As we already said: this is a very advanced topic, and you should think twice before trying to develop a plugin. Both talks gave the impression that metaprogramming is a very powerful tool, but it targets very specific use cases and you should not dive into it just because of all the hype around it.

Some tips grabbed from the talks

Here are some general purpose tips that we learned over the two days. In no particular order:

• You can annotate an extension function with @Receiver:MyAnnotation, to state that this extension only applies on types annotated with @MyAnnotation. - Romain Guy
• It’s super-easy to wrap callback in coroutines to write synchronous-type programming, with suspendCoroutines. - Chris Banes
• Use sealed classes everywhere! - Christina Lee
• Use Arrow’s optics to update immutable nested data classes - Raúl Raja Martínez
• Use sequences instead of collections when more than one processing step is needed - Florina Muntenescu

Conclusion

To conclude, we were quite impressed by the dynamism of the Kotlin community, which seems committed not to be confined to today’s Kotlin main use case: the mobile development (Andrey Breslav quoted a survey in which it appeared that around 60% of Kotlin developers are mobile developers). We are more than ever convinced that its pragmatic aspect, along with built-in features and community dynamism make Kotlin a perfect choice for many types of project.

As a final word, we regret the medium quality of the conf mobile app (no autoscroll to current time slot, loss of favorite talks in the middle of the day). We hope that next year, the app will be a better showcase of this great language capabilities!

You can see the records of the different talks on the Kotlin Conf YouTube playlist