At the eScience Center we mainly use Kotlin for one of the products we are developing namely: UCloud. Therefore, in the beginning of December some of the members of the eScience team were at the KotlinConf 2019 in Copenhagen to get the latest developments and updates on Kotlin. One of the days at the conference was kicked off with the inspirational talk referring to the famous quote from Gene Kranz, who wrote in his book “Failure Is Not an Option”. Reminding us of the responsibility and moral obligation each of us hold when developing new technology and the value of knowing when to say “stop” if technology takes a turn for the worse.

UCloud is an integrated research environment that provides researchers with both computational and storage resources in an interactive environment. It aims to make research and data management easier. UCloud aims to enhance science.

In UCloud we use Kotlin for our entire microservice based backend. We take advantage of several of Kotlins key features, such as: coroutines and DSLs.

Keynote – Day 1

On day one the keynote, Andrey Breslav highlighted recent and future improvements regarding Kotlin. A particular interest was taken to the performance and the general polishing of Kotlin.

Since compile times have become an increasing problem, especially with Kotlin Native, it is great to hear that the performance in these areas will improve.

To do this Kotlin will get a new compiler in Kotlin 1.4.0. This will also bring a new unified backend for Kotlin. Hopefully, this makes it more likely an official compiler API will be available.

Another major topic of the keynote was Kotlin multiplatform. Kotlin is available for pretty much all platforms:

  • Kotlin/JS: Web browser (and desktop/server)
  • Kotlin/JVM: Server, desktop and Android
  • Kotlin/Native: Embedded, desktop, server and iOS

Judging from the keynote and the rest of the conference Jetbrains is aiming to improve the multiplatform experience.

State of Kotlin/JS

The state of Kotlin/JS talk by Sebastian Aigner gave a nice overview of the current state of Kotlin/JS. Unsurprisingly, the talk had a huge focus on Kotlin/JS in the browser.

Using Kotlin/JS is a very interesting idea. At the eScience Center we currently run Kotlin on the backend only. Our frontend is in Typescript. Using full-stack Kotlin has many advantages, as also highlighted in the talk:

  • Share common code between front- and backend
  • Knowledge sharing
  • Ecosystem sharing

One of the major reasons why the eScience Center decided not to use Kotlin/JS was due to the compatibility with existing JS libraries. The main issue here is the dynamic nature of JavaScript versus Kotlin. As a result we would have to write types and interfaces, which should match all our dependencies. This is cumbersome to say the least, and TypeScript faced the exact same problem. Their solution was a community-driven effort to provide type definitions for popular libraries. Today, many popular libraries for JavaScript have matching TypeScript definitions. Jetbrains has taken advantage of this existing effort and have created Dukat. Dukat is a conversion tool between TypeScript definitions and Kotlin definitions. The tool is still in its early stages and appears to be a re-branding of one of their existing tools (ts2kt). Having said that it is very nice to see a re-commitment to interoperability with JavaScript.

Design of Kotlin Serialization

Another big issue has been serialization across platforms. Leonid Stratsev talked about the design of the kotlinx.serialization library. Serialization is the process of converting a data structure (class) to an exchangeable data format. Essentially all server-based applications need to use some form of serialization. UCloud is no exception to this.

In UCloud we use the Jackson library for JSON serialization. This library has worked very well for us. Especially given its support for many data formats, such as Protobuf, XML and YAML. By default Jackson works by utilizing Java reflection. Reflection provides insight into the structure of a class at run-time. As a result this library only works for Kotlin/JVM. In general you need insight into your classes to build a serialization tool. Kotlin/JS and Kotlin/Native have both been lacking in this respect.

kotlinx.serialization solves this problem by hooking into the compiler API of Kotlin. During compilation the library emits code which describe the internals of a class. This grants all platform insight into classes at run-time. As a result it becomes possible to write a general serialization library.
The library currently supports some data formats, including: JSON, CBOR and Protobuf. It also allows users to write their own implementations for other data formats.

The future is looking bright for serialization on Kotlin multiplatform. Consequently, we will definitely be keeping an eye out on the development of this field.

Unlock the power of Kotlin DSL for Kubernetes

Kubernetes is utilized a great deal in UCloud. We use it internally for all our services, but also for our user app orchestration. For the orchestration of user applications we use fabric8’s Kotlin DSL. As a result, we write a great quantity of Kubernetes resources for our microservices.

At the moment, we do not have anything in particular to deal with this cumbersome issue. We write the Kubernetes resources needed by hand for each microservice. We commit the resource files to our git repository. Our microservices share the same core technologies. As a result most of our resource files also share much of the same structure. This results in quite a bit of copy & pasting.

The talk by Fedor Korotkov covers such an approach. The main takeaway here was the possibility to use Kotlin for Kubernetes resources. The talk showcased a demo using fabric8’s DSL for creating some small deployments.

This approach is quite interesting and could solve some of the problems we are facing. Going forward, we intend to explore a Kubernetes + Kotlin solution in the coming year.

Other Interesting Talks

All in all, the KotlinConf 2019 was inspiring and educational. Below are a few other talks we found interesting: