TLDW: Opinionated Wrap-up of KotlinConf 2023 Keynote - JVM Weekly vol. 131

During the hour-long presentation, we learned about the upcoming steps of the Kotlin creators, and a few important statements were made. What’s even more interesting is that some of these have repercussions on broader JVM development.

So, let’s start with Keynote itself:

Have you seen it? If not, I invite you to my summary of the event. Have fun!

Kotlin 2.0 and Kotlin K2

The whole conference started with a big announcement – Kotlin 2.0 is coming. This is not a big surprise, given that the release of 1.9 will be the last in the 1. x line. Version 1.10 will not appear, instead, we will jump straight to the release of 2.0. This is due to the fact that the long-awaited K2 compiler – ‘one to rule them all’ – is planned to be released for this version.

K2 is what is known as the frontend of the compiler. The compilation process is typically divided into two main components: the frontend and the backend. Each of these components plays a separate role in the compilation process.

The compiler’s frontend is mainly responsible for processing the syntax and semantics of the source code. It performs a series of tasks, such as lexical, syntactic, and semantic analysis. During these steps, the frontend checks for syntax errors, generates an AST (Abstract Syntax Tree) representing the program’s structure and ensures that the program adheres to the language’s rules and constraints. The frontend also checks types to ensure that variables, expressions, and function calls are used according to their respective types. After completing these tasks, the frontend generates an intermediate representation (IR) of the source code, which serves as input data for the compiler’s backend. This component focuses on optimizing and generating the final machine code or bytecode for the target platform.

From the above description, it is easy to see that what most of us deal with on a daily basis (whether as end users or even tool creators) is the front end of the compiler. And as it turns out, this part had the greatest potential for optimization. Just look at the numbers that Roman Elizarov boasted about on stage:

However, the solution’s performance itself is not the only issue here. K2 is supposed to provide a common infrastructure for all potential targets of the language. As a result, its developers will not have to implement the same function each time for JVM, WebAssembly or Android, which is expected to speed up Kotlin’s evolution significantly.

The change of a “major” version of a language has been able to stir up a language’s ecosystem a lot, but in the case of Kotlin, JetBrains promises a very stable migration process. First of all, the changes motivating the version bump take place under the hood. The developers deliberately don’t plan to introduce any new innovations in the language’s syntax itself in this release – they’re saving those for the 2.x releases, which will come after the successful transition to K2 (more on that in a moment). In addition, however, JetBrains benefits from controlling both Kotlin and being a major tool provider for it. This allows the whole operation to run much more smoothly when most of the most important tooling can be developed in parallel with the language.

If anyone can’t wait for the new “major” version, last week saw the release of Kotlin 1.8.20, which introduces the -language-version 2.0 flag. This one makes it possible to test the latest changes in the compiler, and Roman Elizarov himself has asked for such testing – this helps catch all bugs and make the whole thing robust.

And as I announced that there will touch new features of the language….

New Syntax

From the stage, Roman Elizarov showed us what we can expect from future releases of Kotlin.

Static Extensions

Well, ladies and gentlemen, Kotlin will receive support for static functions …. sort of.

It will be possible to extend objects with static functions.

fun File.static.open(name: String)

Admittedly, it was already possible to add “effectively static” extension functions, but only if the class had a Companion Object. Now it will also be possible when we do not have control over the base class.

Collections Literals

It’s happening!

Here, let me use a meme:

I think it’s the announcement that Google was waiting for before announcing to the world that Kotlin DSL would become def… No spoilers, we will return to it in a moment.

Object (name-based) destructuring

There will be a puzzle. The following code

<span class="hljs-keyword">data</span> <span class="hljs-keyword">class</span> <span class="hljs-title class_">Home</span>(<span class="hljs-keyword">val</span> country: String, <span class="hljs-keyword">val</span> city: String, )
<span class="hljs-keyword">val</span> (city, country) = Home(<span class="hljs-string">"Kraków"</span>, <span class="hljs-string">"Poland"</span>)

will lead to an error that is difficult to catch – can you see where?

The developers also announced that they are working on introducing a form of object destructuring to prevent such mistakes. There is no syntax proposal ready yet…. that is, there are as many as several, but they are hidden in Kotlin’s YouTrack. We’ll see which one wins in the end.

Explicit Fields

A more obscure change is also the addition of so-called “explicit fields.” This is (at least from my perspective) a syntax sugar over the mechanism referred to as backing fields, and useful when you want to return some value as immutable, but be able to perform some operations in the enclosing class.

That feature is a bit complex (it has its own Design Doc), but in practice, all comes down to changing the following code

class C {
    private val _elementList = mutableListOf<Element>()

    val elementList: List<Element>
        get() = _elementList
        
	  fun addElement(element: Element) {
      _elementList += element // works
    }
}

class C {
   val elementList: List<Element>
        field = mutableListOf()

  fun addElement(element: Element) {
      elementList += element // works
  }
}

// outside code
C().elementList += element // does not compile;

A redesign and stabilization of ContextReceivers, which at one time already made their way into the language was also announced. With the new K2 architecture, it will also be easier to write plugins to the compiler, enabling e.g. code generation.

Kotlin Notebooks

The way we create code is evolving rapidly. On one hand, GPT-4 is becoming a very good partner for collaborative coding at a really fast pace, while on the other hand, techniques previously used mainly by Data Scientists are slowly permeating the rest of the industry. Personally, I really appreciate all kinds of notebooks (although I have to admit that they can be easily abused). So far, however, I have mainly been a consumer of those created by someone else, rather than a create ones myself. This situation may soon change, as JetBrains has decided to create an IDE plugin. And it looks really promising.

Since a picture is worth a thousand words, I made a clip from a part of conference segment where this little gem was presented:

If you’re not sure if it’s worth watching, at the end OpenAI generates Kotlin’s code, because what would a 2023 keynote be without GPT.

For scripting, it seems downright ideal. I remember how much I always appreciated Scala Worksheet.

Now let’s move on, to perhaps the biggest surprise of all….

Kotlin DSL the default dialect of Gradle on Android

I really tried to like Kotlin DSL. It objectively has many advantages, such as improved IDE support and better compile-time safety. Despite being a more expressive alternative to Groovy, its adoption is rather slow. One of the main challenges when working with this dialect is the fact that a significant number of samples, tutorials, and documentation are still in Groovy, not Kotlin. This is mainly because Groovy was originally chosen by Gradle, which led to the creation of a rich ecosystem of content and tools by the community. As a result, developers often have to translate Groovy examples to Kotlin DSL, which can be time-consuming and error-prone due to significant differences in syntax, API, and overall language logic. This makes it difficult for developers to fully benefit from the advantages of Kotlin DSL.

And this is where Google comes in. The company (or rather Grace Kloba, who sits on the Kotlin Foundation board) announced that Kotlin DSL will become the default dialect for Android projects based on Gradle. This is intended to be a push for the rest of the community to abandon Groovy and modernize their builds.

In other words – it was nice to meet you Groovy. It was fun while it lasted.

It’s probably the reason why this morning we had the release of Gradle 8.1, which introduced quite a few additional fixes to Kotlin (but also, for example, support for JDK 20). Indeed, the aforementioned move is described as the result of years of cooperation between Google and Gradle, where the latter responded to constant feedback and helped bring the tool to the point where the declaring Kotlin DSL default could be responsibly made.

And in this way, we can smoothly move on to the next point, which is…

Expansion of the Kotlin Foundation’s membership

This will be brief, as the announcement itself is very clear – the Kotlin Foundation, initially founded by Google and JetBrains, has been expanded to include additional members. In addition to Gradle (which you probably expected), Shopify has also joined. The latter was mainly associated with Ruby, so it was a bit of a surprise, but it turns out that the company actively uses Kotlin Multiplatform.

And at the very end, we will go right to the latter.

Further development of Kotlin Multiplatform

As regular readers of this newsletter probably know (and for new readers, I invite you to subscribe to get to know me better 😄), I mainly work on the backend side. Therefore, Multiplatform has never been more than a curiosity for me, although over time I started to treat this project with a bit more respect. And while announcements such as the change of Jetpack Compose to Compose Multiplatform attract attention, and the release of the latter on iOS certainly catches the eye, I am most excited about the development of the WASM version. For some time now, I have been increasingly interested in WebAssembly and believe that it will become a more important part of the programming ecosystem from year to year.

With that said, be warned, I may be wrong

An interesting fact – if you read the documentation, you’ll find that the entire Compose for Web is based on Kotlin/Wasm. This only shows what a powerful tool we are dealing with.

There was a lot, but I have to admit that I enjoyed myself like at Google I/O from the old days when they showed more new tools for developers than information about changes under the hood of the search engine. And that’s just the Keynote. Tomorrow morning will bring a Coroutines and Loom behind the scenes session led by Roman Elizarov. You can be sure that I will do my little recap… But that’s coming next week.

TLDW: Opinionated Wrap-up of KotlinConf 2023 Keynote – JVM Weekly vol. 131