Kotlin tutorials

Kotlin is easy to write badly if you approach it as Java with a shorter syntax. The type system is the point: nullability is tracked at the type level, so a whole class of runtime failure becomes a compile error, and the idioms follow from that rather than from a preference for brevity.

These guides cover null safety and the operators that go with it, functions with default and named parameters, lambdas and higher-order functions, data classes and destructuring, sealed classes for closed hierarchies, extension functions, and the collections API and how it differs from the Java one it wraps.

Java interoperability gets attention where it matters, particularly around platform types — values arriving from Java whose nullability the compiler cannot verify, which is exactly where a null slips back in.

Collections get particular attention because Kotlin layers its own API over the Java one, and the seams show. The read-only interfaces are not immutable types, map and filter produce new lists rather than views, and sequences exist for the cases where that matters. Knowing which is which prevents both a performance surprise and an unexpected mutation.

Where Kotlin offers several ways to express the same thing — scope functions being the obvious case — the guides pick one and say why, rather than listing five and leaving the choice open. let, run, also, apply and with are distinguishable, and the distinction is worth stating once, clearly.

The examples run on the JVM. Kotlin also targets native and JavaScript, and where a feature behaves differently across targets the guide says so, but the default assumption throughout is a JVM project using Gradle.

Nullability is part of the type rather than a convention, which moves a whole class of failure from runtime to compile time. The exception is the boundary with Java: values arriving from Java code are platform types, which the compiler cannot verify and will not force you to check, so that boundary is where a null pointer exception still reaches production. Coroutines follow the same principle of making structure explicit. A coroutine belongs to a scope, and cancelling the scope cancels the work inside it, so a suspended operation cannot outlive the component that started it.

A theme worth naming up front: most of what surprises people in Kotlin is a default that runs the opposite way to Java's. Classes and members are final unless opened, override is required rather than advisory, a nested class holds no reference to its outer instance, and nullability is part of the type rather than a convention. Each of those removes a class of bug, and each of them will reject code that would have compiled elsewhere.

Interoperability with Java is treated as a first-class concern throughout, since almost no Kotlin codebase exists on its own. Platform types, the use-site annotation targets that decide whether a validation annotation lands on the field or the constructor parameter, and the compiler plugins that make a JPA entity work at all are the three places where the two languages meet and the meeting is not seamless. Each of them is quiet when it goes wrong, which is why they get more space than the syntax does.