Hi everyone! We're the Kotlin team, and we're happy to answer any questions! Joining you today will be:

• /u/mshafirov, the CEO of JetBrains

• /u/abreslav, the lead designer of Kotlin

• /u/yole, the Kotlin tools team lead

• /u/Nikolay_Igotti, the Kotlin/Native team lead

• /u/bashor_, the Kotlin JavaScript team lead

• /u/elizarov, the Kotlin libraries team lead

• /u/orangy, the Ktor team lead

• /u/udalov, Kotlin compiler developer

• /u/ilya-g, Kotlin libraries developer

• /u/yanex, Kotin tools developer

• /u/r4u7, Kotlin tools developer

• /u/hhariri, the lead evangelist of JetBrains

• /u/svtk_, Kotlin developer advocate and "Kotlin in Action" co-author

• /u/wild__lynx, Kotlin tools QA

along with other developers from the team.

We'll be there for you for the next 24 hours. Please ask your questions as top-level comments to this post. Looking forward to hearing from you!

UPDATE And we're done; thanks for all the questions! Note that you can always contact us on the Kotlin Slack or on the forums, so if you missed the AMA, feel free to post your questions there.

I’m a Java dev that has been poking Kotlin for two months.

The sun is finally shining through my boilerplate clouds. Kotlin’s primary value is mostly in its developer experience. I can see myself being happier coding in Kotlin than Java after working through my growing pains.

Java has been the ugly utility language for almost 30 years. Now I have a chance to be beautiful and young, like the next gen of Python mains that still hang from their mothers’ tits.

Coroutines and Null handling are legitimate upgrades. But Kotlin does not have a killer “wow” list of features.

The value that Kotlin brings to me, your beloved anonymous internet stranger, is that it is more pleasurable to write and read than Java.

I’d love to hear other opinions on this.

"We are proud to announce that Meta has officially joined the Kotlin Foundation as a gold member, marking a significant milestone in our ongoing commitment to Kotlin and the broader Android development ecosystem.

Over the past several years, Meta engineers have been actively migrating our extensive Android codebase—comprising tens of millions of lines—from Java to Kotlin. To facilitate this massive transition, we developed an internal tool called Kotlinator, which automates much of the conversion process while ensuring the resulting Kotlin code is idiomatic and compatible with our internal frameworks. We have continued to share these efforts as a part of the enterprise Java-to-Kotlin working group."

https://engineering.fb.com/2025/06/30/android/meta-joins-kotlin-foundation/

Congrats to our friends at Kotlin. 🚀 After years of growth and development, KMP reaches a pivotal milestone with 1.9.20. We’ve been on team Kotlin Multiplatform since day one, and the best is yet to come! Learn more 👉 https://touchlab.co/kotlin-multiplatform-is-stable

https://github.com/Netflix/dgs-framework

Yet another big company using server-side Kotlin.

Hey! It's the Kotlin language evolution team.

We'd like to try to bring more attention to what's happening with the language here and start sharing some updates in a less formal way than KEEPs. We'll see how it goes and whether it turns out to be interesting.

We want to share details about an important upcoming feature (no ETA!) that we discuss today: name-based destructuring. It's the same destructuring we know, but instead of relying on the position of properties, it uses their names. But first, a bit more lyrics.

The current state

Today Kotlin only supports positional destructuring with the well-known syntax: val (x, y) = expr.

And that’s it. This approach has a few drawbacks, where the main one is that positional destructuring doesn't know anything about the names of the destructured properties. As a result, val (x, y) = ... and val (y, x) = ... have different semantics, and it's not clear if that's a problem without looking at the declaration of the data class.

We could’ve even forgotten about the issues with positional destructuring, but we want Kotlin to evolve. For instance, we know we get value classes and a way to destructure their properties. Reusing positional destructuring with its drawbacks seems unacceptable for us. The same goes for potential evolution with regard to pattern-matching capabilities: first, we have to get a solid solution for destructuring and then expand it for more cases like if (p is Person(val name, val lastName) // p -> Person, + name, lastName.

Is positional destructuring that bad?

Oh, not at all. In an ideal world, both positional and name-based destructuring are present and coexist in Kotlin. Positional destructuring is used mostly for homogeneous generic collections like Lists, where destructuring relies on element position: componentN functions essentially delegate to get(N-1) or to names like first, second, and so on (Pair, Triple examples).

However, in the vast majority of cases for data or value classes, we see that such classes are named rather than positional, so name-based destructuring should be the default.

Syntax?

The end goal is to turn the existing syntax val (x, y) = ... to name-based destructuring through a long migration period, and to introduce a new syntax for positional destructuring: val [x, y] = ... as positional destructuring still has many important cases. We also plan to introduce full forms for both positional and name-based destructuring.

Name-based

data class Notification(val message: String, val title: String)

// Name-based destructuring, future syntax

(val message, val title) = speaker // OK, full form
(val title, val message) = speaker // OK, full form

(val text, val message) = speaker // Compiler error, no text property!
(val text = message, val title) = speaker // OK

val (message, title) = speaker // OK, short form
val (title, text) = speaker // IDE warning -> compiler warning (2.X) -> error (2.Y)

Positional

val [x, y, z] = listOfInts // OK
val [f, s] = pair // OK
val [first, second] = pair // OK

Full proposal

See the full proposal here and share your thoughts!