Built for Productivity: What the Data Finally Shows About Kotlin | The Kotlin Blog

Kotlin

A concise multiplatform language developed by JetBrains

Follow

Follow:

X X

RSS RSS

Visit the Kotlin Site

News<br>Built for Productivity: What the Data Finally Shows About Kotlin

Alina Dolgikh

Years of productivity-focused design are now visible in the data.

Pragmatism has been central to Kotlin’s design from day one. The language prioritizes the developer’s convenience and productivity over academic purity or feature ambition.

Developers describe working in Kotlin in a fairly consistent way: more time spent on what you’re trying to build, less time on ceremony. There are fewer rituals to satisfy the compiler, and less boilerplate to write before getting to the part that matters. For years, the interesting question was whether that effect would also be visible at scale.

Now there is data. A recent JetBrains Research study measured the wall-clock cycle from first edit to push across roughly 28 million examples. On comparable work, Kotlin developers spent about 15%–20% less time than developers working in Java.

That gap matters even more right now, as more code is written by AI agents and developers spend more of their time reading, reviewing, and verifying code. We’ll come back to this at the end.

Productivity by design: A short history

Pragmatism becomes concrete when you look at the features it produces. Here are five examples from more than a decade of language and ecosystem design decisions.

Data classes

Some patterns repeat in every codebase. Value objects, DTOs, message envelopes, and configuration records – Kotlin captures these shapes in a single declaration.

data class User(val id: Long, val name: String, val email: String)

There’s one line, value-like behavior, and minimal boilerplate. You get equality, hashing, structural destructuring, toString(), and a copy() constructor automatically. Adding a field doesn’t mean rewriting six methods by hand.

Null safety

Kotlin’s type system tracks whether a value can be absent, and the compiler refuses to let you ignore the question. A whole category of runtime failures becomes compile-time feedback.

val length: Int = user?.profile?.email?.length ?: 0

A nullable chain is expressed in one line, and the compiler verifies every step. Missing values surface at compile time, not later in production.

The small wins

A handful of features quietly remove friction at every call site. Smart casts eliminate redundant typing once a type check has already happened. Named arguments with defaults make configuration readable without builder ceremony. Trailing lambdas turn block-based APIs into something that reads like ordinary control flow.

Each one is small. Together, they shape what a typical function looks like:

fun createUser(<br>name: String,<br>role: Role = Role.MEMBER,<br>email: String? = null,<br>) = transaction { // trailing lambda<br>val user = Users.insert(name, role, email)<br>if (email != null) { // smart cast: email is now String<br>sendWelcome(email.lowercase())<br>user

createUser(name = "Anton", role = Role.ADMIN) // named args + default

Three features compound into one short, readable function.

Coroutines and structured concurrency

Async work in Kotlin reads like ordinary code. suspend functions look sequential but execute concurrently, and structured concurrency ties every async operation to the scope that started it – so nothing escapes and runs in the background unnoticed.

DSLs as a first-class idiom

Productivity didn’t stop at the language. The same syntactic decisions – trailing lambdas, extension functions, type-safe builders – also enable a culture of IDE-aware DSLs across the ecosystem: Gradle build scripts, Compose UI, Ktor routing, Exposed SQL, and HTML and JSON builders. Each is a configuration surface the compiler understands as native code, not a separate format to memorize.

None of these is an isolated win. Each is the product of the same commitment to pragmatism. The rest of this post examines what that commitment looks like in aggregate.

The question stories couldn’t answer

Developers have described Kotlin this way for years: less ceremony and more time on the actual work. But description is not measurement. Whether the same effect would also show up in numbers, at a scale where one team’s opinion doesn’t dominate, is a different question.

Stories don’t scale, and self-reporting has known biases, including the obvious one: People who choose Kotlin want that choice to be justified. A quieter bias is that developers who tried Kotlin briefly and then went back may never be sampled. That’s the gap a study can close.

What the study found

In a recent study, the JetBrains Research team analyzed telemetry from IntelliJ IDEA Ultimate over a 20-month window, from November 2023 to June 2025, covering roughly 320,000 developers and 28 million development cycles. A cycle in this study is the wall-clock time from the first edit of a source file after a...