Kotlin — Cradle to Mastery

Kotlin began as JetBrains' own internal answer to Java's friction points — verbosity, null pointer exceptions, checked exceptions — before Google made it Android's officially preferred language in 2019. That origin as a dogfooded internal tool, not a research project, explains why so much of Kotlin reads as pragmatic fixes rather than academic experiments.

<code>kotlinc</code> can compile a standalone <code>.kt</code> file directly from the command line for learning and small scripts, but any real Kotlin project — especially Android or multiplatform work — reaches for Gradle instead, which this course covers later in the Build Tools lesson.

Kotlin's <code>val</code> declares an immutable reference and <code>var</code> a reassignable one, with <code>val</code> treated as the idiomatic default nearly everywhere — a small syntactic nudge toward immutability that shapes how most real Kotlin code actually gets written.

Kotlin's <code>if</code> can be used as an expression that directly produces a value, not merely a branching statement, and <code>when</code> replaces <code>switch</code> with real added power — matching ranges, types, and arbitrary boolean conditions, not just equality against a constant.

Default parameter values combined with named arguments cover most of the situations Java would force you to solve with method overloading — one function signature handles many call shapes, and named arguments make a call with several optional parameters genuinely readable at the call site.

A Kotlin class cannot be subclassed unless it is explicitly marked <code>open</code> — the exact opposite of Java's default. This is a deliberate design decision favoring composition and explicit intent over accidental, unplanned inheritance hierarchies.

Kotlin interfaces have supported default method implementations since the language's very first release, years before Java added the same capability in Java 8. This let Kotlin interfaces carry real shared behavior from the start, not just method signatures.

Kotlin has no <code>static</code> keyword whatsoever. A <code>companion object</code> — a real, singleton object tied to its class — is the language's actual, more principled answer to the class-level members Java's <code>static</code> provided, and <code>object</code> declarations cover the general singleton pattern beyond that.

Kotlin's type system distinguishes <code>String</code> from <code>String?</code> at compile time, so the compiler — not a runtime crash — is what catches a missed null case. The safe call <code>?.</code>, the Elvis operator <code>?:</code>, and smart casts are the everyday tools built on top of that one distinction, with <code>!!</code> as the deliberately loud escape hatch.

A <code>sealed</code> class or interface restricts every one of its possible subtypes to living in the same file, which is exactly what lets the compiler verify a <code>when</code> expression over it has handled every case — no <code>else</code> branch required, and a new subtype added later breaks the build everywhere it should.

Declaring a class as <code>data class</code> generates <code>equals</code>, <code>hashCode</code>, <code>toString</code>, a <code>copy</code> function for immutable updates, and destructuring components — all derived automatically from the primary constructor's properties alone, eliminating a whole category of Java boilerplate in one keyword.

Kotlin lets you declare a generic type parameter's variance — <code>out</code> for producer-only, <code>in</code> for consumer-only — once, at the class declaration itself, replacing Java's need to repeat <code>? extends</code> or <code>? super</code> at every single call site that uses the type.

The <code>by</code> keyword lets a class implement an interface by forwarding every call to another object that already implements it — real composition, with almost none of the manual forwarding boilerplate that pattern would otherwise require. Property delegation (<code>by lazy</code> and friends) applies the same idea to individual properties.

An extension function lets you add what looks like a genuine new method to <code>String</code> or any existing class — including ones you don't own the source of — without inheritance and without touching the original class at all. It's resolved statically, which is the one real limitation worth understanding.

When a lambda is a function's last parameter, Kotlin lets it move outside the parentheses entirely — the exact syntax trick behind every readable DSL-style Kotlin API, including the standard library's own scope functions and Gradle's Kotlin DSL.

Kotlin's five scope functions — <code>let</code>, <code>run</code>, <code>with</code>, <code>apply</code>, <code>also</code> — differ from each other in exactly two dimensions: how you refer to the receiver inside the block (<code>it</code> vs. <code>this</code>), and what the whole expression returns (the receiver itself vs. the lambda's result). Once those two axes click, choosing between them stops being guesswork.

A lambda with a receiver — where the lambda body can call the receiver's members directly with no qualifier — is the precise language feature behind Gradle's own <code>build.gradle.kts</code> readable syntax, and the same technique is available to build your own internal DSLs.

Kotlin's <code>List</code> interface is read-only, not necessarily immutable: the same underlying data might still be mutated through a different reference that holds it as a <code>MutableList</code>, so "read-only" and "immutable" are genuinely different guarantees worth telling apart.

Kotlin has no checked exceptions whatsoever, a deliberate rejection of a Java design JetBrains considered, in practice, a failed experiment — one that pushed developers toward empty catch blocks and blanket <code>throws Exception</code> declarations more often than genuinely correct error handling.

A single Kotlin property can compile down to several distinct underlying JVM elements — a field, a getter, a setter, a backing field — and an annotation's use-site target (<code>@field:</code>, <code>@get:</code>, and so on) is how you tell the annotation processor exactly which one to attach to.

Coroutines let you write sequential-looking code for genuinely asynchronous work — <code>suspend</code> functions, <code>launch</code> for fire-and-forget work, <code>async</code>/<code>await</code> for a result you need back — and <code>Flow</code> extends the same idea to a stream of values arriving over time rather than a single result.

Structured concurrency is coroutines' real safety guarantee: a parent coroutine genuinely cannot complete until every child coroutine it launched has itself finished, which is exactly what prevents orphaned background work from silently outliving the scope that was supposed to own it.

Calling Java code from Kotlin opens a genuine hole in null-safety, since Java declares no nullability information the Kotlin compiler can check. Platform types (shown as <code>String!</code>) are Kotlin's honest, visible acknowledgment of exactly that gap, rather than a false promise of safety Kotlin can't actually back up.

Kotlin Multiplatform's <code>expect</code>/<code>actual</code> mechanism lets shared code declare what every target platform must provide, while each platform's own module supplies its own real implementation — sharing business logic across Android, iOS, and other targets without sharing what genuinely has to differ per platform.

Kotlin/Native compiles Kotlin code directly to a native binary through LLVM, with no JVM and no bytecode involved at all — which is precisely why it exists: it's what lets Kotlin Multiplatform actually target iOS, where there is no JVM to run bytecode on in the first place.

Gradle's Kotlin DSL (<code>build.gradle.kts</code>) gets full IDE autocomplete and compile-time type checking directly on your build script — something the older Groovy DSL, being dynamically typed, could never genuinely offer.

<code>kotlin.test</code> is a thin, Kotlin-friendly, multiplatform-compatible wrapper directly over JUnit's assertions, while Kotest goes considerably further with a genuinely different, more expressive testing DSL of its own — worth knowing both, since real Kotlin codebases use either.

Jetpack Compose replaces Android's traditional XML layouts and <code>findViewById</code> calls entirely: a composable function describes the UI as a direct function of the current state, and Compose automatically re-runs that function whenever the state it reads actually changes.

Kotlin's everyday collection operations like <code>map</code> and <code>filter</code> are eager by default — each step in a chain builds a complete new list immediately, even when you only actually need the first matching result — which is exactly the case <code>sequences</code> exist to handle lazily instead.

This lesson is the course's synthesis and capstone: data classes, extension functions, the five scope functions, the collections API, and destructuring declarations &mdash; the individual features from across this entire course, seen together as the actual idiomatic style real Kotlin codebases are written in, not just a list of language features in isolation.