Kotlin: What and Why

Kotlin

2026-08-21 09:00

Where we are

The first question

The JVM already had Java.

And Groovy, Scala, Clojure, JRuby, Jython.

So why another one?

Kotlin’s pitch is modest

No new computational model.

No abandoning your libraries.

No abandoning your existing code.

The claim is a conjunction

statically typed · concise · safe · interoperable

Each on its own is unremarkable.

All four at once is the whole argument.

What you will be able to do

1. Read a short Kotlin program and name what makes it short.
2. State Kotlin’s primary traits.
3. Explain static typing with inference.
4. Describe the functional side and its benefits.
5. Place Kotlin in its application areas.
6. State the four design commitments.
7. Describe how Kotlin is compiled.

One thread to watch

Nearly every design decision traces back to interoperability.

Kotlin could have been safer, more concise, more purely functional —

if it were willing to break from Java. It is not.

The compromises that follow from this are more interesting than a clean-sheet design would have been. Flag it now; it pays off in the type system unit.

A first taste

Nine lines

data class Person(val name: String,
                  val age: Int? = null)

fun main(args: Array<String>) {
    val persons = listOf(Person("Alice"),
                         Person("Bob", age = 29))

    val oldest = persons.maxBy { it.age ?: 0 }
    println("The oldest is: $oldest")
}

The oldest is: Person(name=Bob, age=29)

The Java equivalent

Several dozen lines.

Most of it mechanical.

What is doing the work

• data class — equals, hashCode, toString generated
• default parameter value — age defaults to null
• type inference — List<Person> never written down
• lambda — a function passed as a value
• Elvis operator — ?: supplies a fallback
• string template — $oldest in the string

And in the type itself

val name: String     // may never be absent
val age: Int?        // may be absent

Enforced by the compiler.

The single feature Kotlin is best known for.

Do not master this yet

Its purpose is to make later units read as explanations

rather than a list of features arriving from nowhere.

But register two things

No boilerplate. No getters, no constructor body, no equals.

The query describes the result, rather than a procedure for getting it.

Statically typed without the noise

Every type is known

Like Java. Unlike Groovy or JRuby.

The compiler verifies that what you call actually exists.

You just do not write it

val x = 1                  // Int
val name = "Kotlin"        // String
val list = listOf(1, 2, 3) // List<Int>

Every one is as strongly typed as a declaration with the type spelled out.

What static typing buys

• performance — no runtime method resolution
• reliability — the compiler checks consistency
• maintainability — you can see what things are
• tool support — refactoring, completion, navigation

What it usually costs

Map<String, List<Person>> m = new HashMap<String, List<Person>>();

The same thing, said twice, and neither half optional.

The pattern to notice

Kotlin does not remove a guarantee to gain convenience.

It keeps the guarantee and removes the ceremony.

Watch for it in nullability, smart casts, data classes, delegated properties.

This is the closest thing Kotlin has to a single design principle. Repeat it whenever a new feature turns out to be an instance of it — which is often.

Functional and object-oriented

Not a compromise position

Classes, interfaces, inheritance — all still there.

Plus a full functional capability.

You choose per problem, not per language.

Three ingredients

• First-class functions — functions are values
• Immutability — objects that cannot change
• No side effects — same inputs, same result, nothing touched

Three benefits

Conciseness — a function-as-value replaces a block of code.

Safe multithreading — immutable data cannot be corrupted by concurrent access.

Easier testing — no setup, no mocks. Call it, check the result.

The middle one is the strong claim

Not “helps you manage synchronisation bugs”.

Eliminates the category. There is nothing to corrupt.

Where Kotlin is used

Server-side

Web applications, backends, microservices.

Not because Kotlin is better at HTTP.

Because it uses every Java framework unchanged, one file at a time.

Android

Where the benefits concentrate.

Many small screens → boilerplate matters.

A NullPointerException → a crash the user sees.

And a preview

createHTML().table {
    for (person in persons) {
        tr {
            td { +person.name }
            td { +person.age.toString() }
        }
    }
}

Country.select { Country.name eq "Kotlin" }

Look twice

Both look like new syntax.

Neither is.

Ordinary Kotlin — functions, lambdas, operator conventions.

Notice what the first one does

A for loop inside markup.

Type-checked. Completed by the IDE.

No template engine can offer that.

Unit 11 builds one of these, using machinery from units 3, 5, 7 and 8. None of those features was introduced for DSLs. That is the module’s real argument.

The philosophy

Four commitments

Pragmatic · Concise · Safe · Interoperable

Between them they explain nearly every design decision.

Pragmatic

A practical language for real problems.

Not a research vehicle. Features mostly proven elsewhere.

And no imposed architecture.

Concise

Reading takes longer than writing.

So remove the ceremony, and the reader sees intent.

But not cryptic operators. Short is not the goal; clear is.

Safe — nullability

val s1: String = null   // will not compile
val s2: String? = null  // fine

The most common runtime failure on the JVM —

converted into a compile error.

Safe — smart casts

if (value is String)
    println(value.toUpperCase())   // no cast

Java requires the check and the cast. The same fact, twice.

Same principle as type inference, applied to control flow.

Interoperable

Kotlin calls Java. Java calls Kotlin.

Kotlin’s collections are Java collections.

Which is the only way a language ever gets adopted at all.

What this commitment costs

Bills that come due later in the module:

• platform types — Java carries no nullability information
• collection mutability — read-only views Java can still modify

Both compromises. Both more instructive than the clean design.

From source to bytecode

The pipeline

By hand, once

kotlinc hello.kt -include-runtime -d hello.jar
java -jar hello.jar

In practice: Gradle, Maven, or the IDE.

Plus the Kotlin runtime library — small, shipped with the application.

Why this justifies the claim

Kotlin produces the same artefacts Java does. Therefore:

• Java libraries work without adaptation
• Java calls Kotlin classes as Java classes
• a .kt file compiles alongside a Java project
• profilers, debuggers, build systems keep working

Not aspirational

The interoperability commitment

falls out of the compilation model.

Summary

What you can now recognise

A short program and what makes it short.

The traits, the philosophy, the toolchain.

Nothing explained fully. Everything returns.

The six things to carry away

• The claim is a conjunction — four properties at once, not one feature.
• Static typing survives having almost no annotations. Guarantee kept, ceremony dropped.
• Functional and object-oriented, so you choose per problem.
• Safety means the type system — String and String? are different types.
• Interoperability explains the compromises as well as the strengths.
• The DSL examples are ordinary Kotlin. That is where this module ends up.

Where next

Kotlin Basics stops surveying and starts teaching.

Functions and variables, classes and properties, when, smart casts, loops, exceptions.

By the end you write small programs instead of only reading them.