Kotlin 2.0: The K2 Compiler and the New Era of Development

Guest: Thanks, Alex! It’s great to be here. Honestly, I’ve been waiting for this 2.0 release for what feels like a decade, so I have a lot of thoughts. Host: Oh, I bet. So, let’s start with the big one. Everyone is talking about the K2 compiler. To the average developer who just wants their code to run, what happened under the hood? Why is this a "new era"? Guest: Right, so, the best way to think about it is that the "frontend" of the compiler—the part that actually reads your code, checks for errors, and figures out your types—was getting... let’s say, a bit "crusty." It was full of technical debt from years of adding features. With Kotlin 2.0, they basically threw that old frontend away and built a new one from scratch using what they call FIR, or Frontend Intermediate Representation. Host: And that translates to speed, right? I saw some benchmarks claiming up to two times faster compilation. Is that actually what you’re seeing in real-world projects, or is that just "marketing speed"? Guest: (Laughs) You know, I’m always skeptical of benchmarks too. But honestly? Yeah, it’s legit. On our main project at HexaTech—which is a pretty massive monorepo—we saw our clean build times drop by about 35%, and incremental builds are significantly snappier. The biggest thing for me isn't just the final "build finished" message, it’s the initialization phase. K2 is way more efficient with memory, so the compiler doesn't "choke" as much when it’s first starting up. It makes that feedback loop feel much more "live." Host: That is huge. I mean, minutes saved every day really add up. But beyond speed, I’m curious about the "Smart Casts 2.0." I’ve definitely had those moments where I’m like, "Come on, Kotlin! I just checked that this variable isn't null two lines ago, why are you making me use the bang-bang operator or an extra check?" Guest: (Laughs) Oh, we’ve all been there! The "smart cast struggle" is real. K2 is much more sophisticated now. It tracks variable states across logical operators and even inside closures. For example, if you have a local variable and you check its type, and then you use it inside a lambda or a closure—as long as that variable isn't being modified—K2 can now "remember" that type. Host: That’s such an "aha" moment when you realize the compiler is finally catching up to how we actually think. Now, I want to talk about Kotlin Multiplatform, or KMP. That’s been a big focus for Allur listeners lately. How does 2.0 change the game for sharing code between Android, iOS, and the web? Guest: This is actually the part I’m most excited about. Before 2.0, the compiler frontend was kind of fragmented. There was different logic for the JVM target versus the JS target, which meant you’d sometimes get weird, inconsistent bugs where something worked in "common" code but failed when targeting iOS. Host: Wait, so is Kotlin/Wasm actually ready for production-ish use? Or is it still just a "cool toy" phase? Guest: I’d say it’s in the "early adopter" phase. I wouldn’t move a banking app to it yet, but for high-performance browser tools or serverless logic? It’s getting very fast. JetBrains is positioning Kotlin to be a first-class citizen in the Wasm ecosystem, and 2.0 is the foundation that makes that possible. Host: Interesting! Okay, so let’s talk about the "scary" part. Migration. Whenever I hear "complete rewrite" and "2.0," my brain immediately goes to "everything is going to break." If I’m sitting on a Kotlin 1.9 project today, how painful is it to jump to 2.0? Guest: Honestly? It’s surprisingly boring—in a good way! (Laughs). For about 90% of developers, you literally just go into your Gradle file and change the version number to `2.0.0`. JetBrains worked really hard on backward compatibility. I’ve updated three different projects now, and the code itself didn't need any changes. Host: That makes sense. And what about the IDE? I’ve heard that to really feel the K2 speed, you can't just update the compiler; you need the right version of IntelliJ or Android Studio. Guest: Exactly. You want to be on IntelliJ 2024.1 or later, or at least Android Studio Iguana. The IDE actually uses the K2 engine now for things like code completion and error highlighting. Have you ever had those "ghost" errors? Where the editor shows a red squiggle, but the build actually succeeds? Host: Oh, all the time! It drives me crazy. Guest: Right! That usually happens because the IDE’s analysis was out of sync with the compiler’s analysis. But now, because they both use the K2 frontend, that gap basically disappears. What you see in the editor is exactly what the compiler sees. It’s a much more "honest" development experience. Host: "Honest development experience." I love that. It really feels like Kotlin is maturing into this "all-rounder" language that isn't just for Android anymore. Marcus, before we wrap up, if someone is listening to this and they’re on the fence about upgrading today, what’s your one-sentence pitch for them? Guest: I’d say: Do it for the build times, but stay for the smarter casts and the future-proofing. It’s the smoothest "major" upgrade I’ve ever seen in the JVM world. Host: That’s a bold claim, but given how much work they’ve put in, I believe it! Marcus, thank you so much for breaking this down for us. Where can people find you or follow your work? Guest: You can find me on X—or Twitter, I guess—at @mthorne_dev, or over at the Kotlin Slack. I’m always hanging out in the #multiplatform channels.