val, var & Type Inference

Let's start writing Kotlin. The very first thing you type - declaring a variable - already shows Kotlin's personality: immutability is the default, and the compiler figures out types so you don't repeat yourself. Two keywords, val and var, replace Java's final-or-not distinction, and type inference removes the noise. It's a small change you'll use in every line, and it nudges you toward safer code.

val vs var: immutable by default

Kotlin has exactly two ways to declare a variable:

• val (value) - a read-only reference, assigned once. It's like Java's final: you can't reassign it.
• var (variable) - a mutable reference you can reassign, like a plain Java variable.

val name = "Ada"       // read-only: reassigning is a compile error
var count = 0          // mutable: count = 1 is fine
count = 1              // OK
// name = "Grace"      // ERROR: val cannot be reassigned

Compare the Java you'd write for the same intent:

final String name = "Ada";   // Kotlin: val name = "Ada"
int count = 0;               // Kotlin: var count = 0

The difference is cultural: in Java, final is extra typing most people skip, so mutability is the lazy default. In Kotlin, val is the shorter word, so immutability is the path of least resistance. You reach for val first and only switch to var when you truly need to reassign - which, in practice, is less often than you'd think.

Type inference: say it once

Kotlin is statically typed - every variable has a fixed type checked at compile time, exactly like Java. But you rarely write the type, because the compiler infers it from the value:

val name = "Ada"        // inferred: String
val count = 0           // inferred: Int
val price = 19.99       // inferred: Double
val ready = true        // inferred: Boolean

This is not dynamic typing (like JavaScript or Python) - name is a String forever, and name = 5 is a compile error. It's the same idea as Java's var (since Java 10), but Kotlin uses it pervasively. You can write the type explicitly when it aids clarity or when there's no initializer:

val total: Double = 0.0          // explicit type for clarity
val user: User = fetchUser()     // explicit when the inferred type isn't obvious at a glance
var result: String               // required when there's no initializer yet

The guideline: let inference handle the obvious cases (a String literal is clearly a String), and annotate when the type isn't obvious from the right-hand side or when you want to document intent.

Why immutability-first matters

Defaulting to val isn't just tidiness - it prevents a whole class of bugs. An immutable reference can't be accidentally reassigned halfway through a method, can't be mutated by another thread, and makes code easier to reason about (once set, it stays). It's the same lesson as value objects and final fields from the Java and architecture paths - Kotlin just makes the safe choice the default choice, so you fall into good habits without effort.