KotlinConf 2025 Announcements

Oh man, this KotlinConf was something. Certainly better than the last one, when the greatest announcement was faster Kotlin build time. This year, K2 is finally stable, and new features have begun to flow into Kotlin. We had some great announcements, like rich errors, name-based destructuring, and much more. I am not even sure where to start, so I will just try to summarize the most important ones chronologically, as they were announced.

Name-Based Destructuring

That might seem minor, but you wouldn't believe how many people asked me about this feature. As I am teaching people with JavaScript or Swift background, they constantly ask me about name-based destructuring, that now seems to be an absolute mast-have in many languages. It will soon be available in Kotlin as well. The syntax will include using val or var inside the destructuring brackets, like this:

data class Person(val name: String, val surname: String, val age: Int) val person = Person("John", "Foo", 30) (val name, val age) = person println("Name: $name, Age: $age") // Output: Name: John, Age: 30

For this code to compile, variable names must match property names, but they can be specified in any order. It will work in lambdas or loops.

val people = listOf(Person("John", "Foo", 30), Person("Jane", "Bar", 25)) for ((val surname, val name) in people) { println("Surname: $surname, Name: $name") } people.forEach { (val name, val surname) -> println("Name: $name, Surname: $surname") }

This feature was announced to become experimental in Kotlin 2.4 (so next year). I am not that sure about the syntax, but I do not have any better idea. I am just happy that it is finally coming.

Rich Errors

That is going to be the greatest change in Kotlin since it became stable. Kotlin does not support checked exceptions, because according to the best practices, exceptions should not be used for signaling expected situations. To deal with such situations, it is a best practice to either use Result type or nullable result.

fun fetchUser(id: String): Result<User> { // ... } fun getUserOrNull(id: String): User? { // ... }

However, those options are not always satisfactory. Result cannot type-safely express what kind of exceptions it can contain. It can also be easily ignored, and it does not have any idioms that would allow operating on it in a simple way. That is why we need a better way to express errors in Kotlin.

I already wrote about rich errors last year, when they were still known as "Union types with errors". Their original name was longer, but it clearly expressed what they are - types that express either a result or an error. A lot like Either from Arrow, but with build-in support in the language.

Rich errors will have similar support as nullable types. So they should support:

?. safe call operator - that will call the right-hand side only if the left-hand side is not an error, otherwise it will return the error.

?: elvis operator - that will return the right-hand side if the left-hand side is an error, otherwise it will return the left-hand side.

!! not-error assertion operator - that will throw an exception if the left-hand side is an error, otherwise it will return the left-hand side.

Overall, experience with rich errors should be similar to nullable types, but with more information about the error.

Plugins joining Kotlin ecosystem

I was a bit surprised by this announcement. For years, Kotlin was intentionally extracting many features into external plusing, like Power Assert, Kotlin Serialization, Binary Compatibility Validator, Dokka or Kover. Now Vsevolod Tolstopyatov announced that those plugins will be distributed as a part of Kotlin plugin. You will not need to add separate dependencies to use them, they will be available out of the box, they might only need to be enabled or configured in Gradle build script.

More about it here.

Agents and MCP in Kotlin

Man, there was a lot about AI in KotlinConf 2025. It is quite clearly a priority for JetBrains (do not worry, new teams were formed to work on those new features, so it will not slow down the development of other features).

Opening keynote had its big section about AI, and there were quite a few sessions about it. Except for a very simple things, like Kotlin SDK to use different AI models (come on, one could write a custom Open AI or Anthropic SDK in a couple of hours, and Spring AI is currently just a simpler way to use those on Spring), I think the most interesting announcement was MCP Kotlin SDK, and a library to define agents in Kotlin.

MCP (Model context protocol) is a protocol created by Anthropic that standardizes how applications provide context to LLMs. It is now widely adopted by many AI providers (surprisingly even Google adopted it instead of creating their own). Good that we can now use it simply in Kotlin as well.

The second big announcement was Koog, a new framework from JetBrains to define agents in Kotlin. I must say, it looks very promising, and I am looking forward to trying it out.

Compose Multiplatform for iOS is now stable

Quite clearly JetBrains works hard on making Compose Multiplatform work nicely on all platforms. There were many improvements made over the last year, and now Compose for iOS is finally stable.

I am happy with this announcement, I am just waiting now until Compose for Wasm becomes stable as well.

Coroutines Debugging has been improved

That was announced in a lightning talk, not in the main keynote, but I think it is worth mentioning. Coroutines debugging has been significantly improved. Since Kotlin 2.2, local variables will not be optimized out in debug mode. In recent versions of IntelliJ and Android Studio, step over, step into, and step out actions will guarantee to stop at the same coroutine. They also announced that exception stack traces will soon include not only the last function call, but all suspending function that were called before the exception was thrown. That will be a great improvement, and I am looking forward to it.

Coroutines Mastery

Time for our announcement. As a part of Kt. Academy vision to create a next-level learning experience for Kotlin developers, I am happy to announce that we will start the first edition of the Coroutines Mastery course. During 5-weeks of course, our aspiration will be to turn all participants into experts in coroutines. We hope to make another generation of conscious Kotlin users, introducing new quality standards, and uplifting our whole community. Keep your fingers crossed for us.