Space

Just before the party kicked of on day one of KotlinConf, Maxim Shafirov, CEO of JetBrains, announced the company's newest product: Space.

Space is an integrated team environment, with which JetBrains takes on Atlassian, Micrsoft and Slack all at once. It promises features like team management, chat, IDE integration, issue tracking, VCS and much more. And it's all built with Kotlin! It potentially substitutes literally all inter-communication tools of a company 🤯 The demo looked very promising, so we're really looking forward to see what becomes of it.

Day 2

Talks

The second day of KotlinConf began with a story about risk management in the NASA Space Shuttle program, held by Stephen Carver. He talked about how an organisational culture can become so bad that communication between departments becomes non existent, and how this ended with astronauts loosing their lifes. Not just once, but twice.

Failure is not an option - Error handling strategues for Kotlin programs

[@portabletext/react] Unknown block type "__block", specify a component for it in the `components.types` prop This talk by Nat Pryce and Duncan McGregor revolves around error handling in Kotlin. As we know, Kotlin has largely inherited Java's exception mechanisms but, as the two brits put it: "exceptions and functional programming are uneasy bedfellows, leading to most projects adopting a wing-and-a-prayer as their error handlign strategy". So, how should we do it in Kotlin? Well, it depend.

For simple cases such as parsing an int from a string, they have found that null can work as an error. However, our world is rarely simple, so they outlined two other solutions; the familiar exceptions and the "Result" type. When throwing exceptions, they recommended "fuzzy" tests to ensure that there weren't any unexpected exceptions. When using the "Result" type, they suggested to prefer immutable data and delegate handling of failures as high up the stack as possible by propgating the failure Result. To provide the Result type and utilities, they proposed the use of Result4k in specific situations. Your milage may vary, though.

What's new in Java 19: The end of Kotlin? 🤔

Another interesting talk was by Jake Wharton, where he compares new and upcoming features in Java with Kotlin of today. As he aptly illustrates, since the emergence of Kotlin, the developers of Java seems to have stepped up their game - but is it enough?

Throughout the talk, he illustrated his points through code, albeit with some artistic freedom when it came to overriding a deconstructor. Take value-based classes as an example. In Kotlin, we have the well known data class, like so;

data class Person(val name: String, val age: Int)

With the proposed record in Java, a similar construct would look like this;

record Person(String name, int age) {}

Combined with the new deconstructors which he also mentiones, the only big difference would be the copy constructor! 😱

Another advantage to Kotlin as of today is Sealed class, described by many as Enum on speed. To recap, this is a Sealed class

sealed class Customer
data class Person(val ssn: String, val firstName: String, val lastName: String) : CustomerID()
data class Company(val id: String, val name: String) : CustomerID()

A little down the road, it looks like Java will have a similar construct

sealed interface CustomerID {}
record Person(String ssn, String firstName, String lastName) : CustomerID()
record Company(String id, String name) : CustomerID()

When you factor in other topics he mentioned, like Variable Type Inference, Expression Switch and Pattern Matching, it can indeed look somewhat gloomy for Kotlin. However, all of these changes will also benefit Kotlin, given that it's also on the JVM! Add in things such as Kotlins multiplatform support and Null as part of the type system, he answered with nope - we will still need Kotlin.

Android Jetpack ❤️

In 2017 Android announced first-class support for Kotlin, and since 2017 both the platform and the language has evolved a lot. That is why this year Google announced that Android will become Kotlin-first. In this talk Wojtek Kaliciński talked about the current state of Android Jetpack, which is a suite of libraries for app development on Android. Part of the talk was also to present how the future will look like for the API development on Android.

Included in Android Jetpack is Android KTX which is a set of Kotlin extensions that build upon the already existing Java API. It utilises Kotlin language features such as extension functions, lambdas, coroutines and more. By using Kotlin language features to build upon the existing API you get a much more concise approach to using some parts of the API.

Wojtek Kaliciński presented a very nice example of how utilising Kotlin to improve Android Jetpack improved the overall experience of using the library. He did so using SharedPreferences, which is an interface to access and modify preference data on an Android device.

With the old approach you have to first create an Editor, put in the desired values with the associated keys, and then asynchronously write to disk. By using extension functions and lambdas, we're able to do all this in one call where we supply a lambda with the desired change.

sharedPreferences
        .edit()
        .putBoolean("key", value)
        .apply()

And look how much better this is with the Android KTX extension 🤩

sharedPreferences.edit { putBoolean("key", value) }

The future of both the Kotlin language and the Android platform is looking bright! ☀️