Kotlin.CodeCompared.To/Scala

Scala 2 has no top-level def, so the entry point lives in an object — a singleton, which is exactly Kotlin's object declaration and in fact where Kotlin borrowed the idea. def is fun, Unit is Unit, semicolons are optional, and the body after = is an expression. Scala 3 adds top-level definitions and an @main annotation, which collapses this to almost exactly the Kotlin form.

Identical semantics, and by lazy { } becomes the keyword lazy val — same memoization, same thread safety, one less delegate. The difference underneath is that Kotlin's by is a general delegation mechanism (you can write your own), while Scala's lazy is baked into the language. Scala also allows val in a trait, and even lazy val as a class member that a subclass may override — which is how a lot of Scala configuration is wired.

Interpolation is a library feature wearing syntax: s"…" calls the s method on a StringContext, and because it is an ordinary method you can add your own (a json"…" or sql"…" interpolator that validates at compile time is a common trick, and has no Kotlin equivalent). f"…" is the one to remember day to day — it is String.format with the format string type-checked against the argument. Multi-line strings use stripMargin with a | rather than trimIndent(), which is uglier but more explicit about where the margin is.

Kotlin got most of the way here — if and when are expressions — but loops are not, so building a list means a mutableListOf and a pile of add calls (or a switch to map). In Scala for … yield produces a value, so the imperative and the functional form are the same construct. The other habit to drop is return: it exists, but it is a non-local jump, it is discouraged, and writing one in a lambda will surprise you. The last expression of a block is the value; that is the whole rule.

There is no operator table because there are no operators: a + b is a.+(b), and any method taking one argument can be written infix without Kotlin's infix keyword. That symmetry is what makes libraries like Cats and Akka read the way they do — and it is also the reason Scala has a reputation for line-noise, since nothing stops a library from naming a method <*> or |@|. Kotlin's fixed list is the deliberate reaction to exactly this. One rule worth knowing: a method whose name ends in : is right-associative, which is why 1 :: list prepends rather than appends.

The consequences run deep. Because Option is a value, it composes with every other value: it goes in a List, it is pattern-matched, it flows through a for-comprehension, and the same map/flatMap/getOrElse vocabulary works on List, Either, Try and Future. Kotlin's ? is erased at run time and costs nothing, but it is special-purpose syntax — ?. works on nullables and nothing else, and there is no way to write a function that is generic over "things that might be absent". The price Scala pays is an allocation per Some, and the fact that null still exists on the JVM underneath (it leaks in from Java, and idiomatic Scala wraps it immediately with Option(javaValue)).

The mapping is mechanical once you see it: ?. on a value-returning call is map, ?. on a call that itself returns an optional is flatMap, ?: is getOrElse, and mapNotNull is a flatMap. What is not mechanical is that these are the same methods a List has — List.flatMap and Option.flatMap mean the same thing, which is why people.flatMap(_.address) above drops the empty ones without a special combinator. And fold(ifEmpty)(ifPresent) is the total version: it forces you to handle both branches, and returns a plain value.

The vocabulary is close enough to guess at — joinToString is mkString, sumOf { } is map(…).sum — and _ is it, with one catch: each _ refers to a different parameter, so list.reduce(_ + _) means (a, b) => a + b, and you cannot use _ twice for the same value. The genuinely new tool is collect, which takes a partial function and keeps only the elements the pattern matches — a filter and a map and a destructuring in one, and the thing you will reach for constantly once it clicks. Note also that List here is truly immutable and persistent (a cons list), not a read-only view over a mutable one.

Kotlin's List is a read-only interface over what may well be a mutable ArrayList — someone holding the other reference can still change it under you. Scala's List is persistent: adding an element returns a new list that structurally shares its tail with the old one, and no reference anywhere can mutate it. That is a real guarantee rather than a promise, and it is why Scala can hand collections between threads without a thought. The cost is that you must think about which operations are O(1) on a cons list (prepend) and which are O(n) (append, indexing) — reach for Vector when you need both ends.

view is asSequence() and LazyList is generateSequence — same laziness, same fusion, same requirement to force it at the end. The one extra idea Scala has is that LazyList memoizes as it goes, so a value is computed once no matter how many times you traverse it; a Kotlin Sequence is single-pass and will happily re-run its work if you iterate it twice. (This was called Stream before 2.13, and you will still see that name in older code and in every Scala tutorial written before 2019.)

Kotlin gives you Pair and Triple and then tells you to write a data class — sensible advice, and a real friction point when a function just needs to return three things. Scala has tuple literals up to 22 elements, they pattern-match, and a -> b is an ordinary method that builds one (which is why the same arrow appears in Map literals). The advice is still to name your types when they mean something; the difference is that Scala does not force it on you at element three.

Nothing to relearn: defaults and named arguments work the same way, and skipping a middle argument by name works too. The one habit to add is the =: a method whose body is an expression is written def f(…): T = expr, which is Kotlin's expression body under the same sign. Omitting the = (the old "procedure syntax") makes the return type Unit, silently discarding your result — it is removed in Scala 3, for exactly that reason.

The payoff is not the currying itself but what it enables. Type inference proceeds one parameter list at a time, so transform(list)(lambda) can infer the element type from the first list and use it to check the second — which is why Scala lambdas so rarely need type annotations. A brace-delimited final list is what makes Scala DSLs look like language constructs. And the mechanism generalizes: an implicit parameter list is just one more list, which the compiler fills in for you. Kotlin's trailing-lambda syntax buys the prettiest use case of this and none of the rest.

A by-name parameter is written x: => T and is not a lambda: the caller writes an ordinary expression, and the callee decides whether — and how often — it is evaluated. That is what lets Scala define control structures that look built in, and it is why logged(false)(expensive()) above prints nothing at all despite the call parentheses being right there. Kotlin gets the same laziness by taking a () -> T lambda and marking the function inline so the closure allocation disappears; the cost is that the call site must show the braces. Watch the trap in both languages: a by-name parameter used twice evaluates twice, so bind it to a lazy val if you need it memoized.

A PartialFunction is a function that carries its own domain: it can be asked isDefinedAt, and it can be composed with orElse to cover the gaps. That is what makes collect possible, and it is why Akka actors are written as a block of case clauses — the actor's message handler literally is a partial function, and messages it is not defined for are handled elsewhere. Kotlin has no such concept: a lambda is total, so filtering and mapping stay two separate operations, and there is no way to ask a function which inputs it accepts.

Same generated members (equals, hashCode, toString, copy), same value semantics — the fields are val by default, so you do not even write the keyword. The difference is what a case class also gets: an unapply method, which is what makes case Person(name, age) work in a pattern. Kotlin's destructuring is component1()/component2() — positional, and usable only in a destructuring declaration or a for. Scala's is a real pattern, so it works in match, in val, in a lambda's case, and nested arbitrarily deep.

Kotlin's companion object and operator fun invoke are both borrowed from here, so apply will feel familiar. unapply is the half Kotlin did not take, and it is the more interesting one: defining it makes your type usable on the left of a case, so pattern matching is extensible by any class, not just data classes. That is how case Some(x), case head :: tail, and every regex or JSON extractor in the ecosystem work — they are ordinary objects with an unapply method.

Two differences that matter. A trait can hold state (var greetings), which a Kotlin interface cannot — Kotlin interfaces may declare a property but never store it, so shared state has to be re-implemented in every class. And super inside a trait is resolved at mix-in time, by linearizing the traits right to left: with Loud with Counting means Counting.greet runs first and its super call lands in Loud. That is the "stackable traits" pattern, and it makes each trait a composable decorator. It is also the sharpest edge in the language: reorder the with clauses and the behavior changes, silently.

Kotlin's when (shape) { is Circle -> … } tests the type and smart-casts, but the value stays whole — you write shape.radius. Scala's pattern takes it apart in the same breath, nests to any depth (case Some(Circle(r))), binds a whole subpattern with @, and takes a guard with if. A block of case clauses is also a function literal, which is why foreach { case … } above needs no lambda parameter at all. One caution: an inexhaustive match on a sealed type is a warning in Scala, not an error like Kotlin's — turn on -Xfatal-warnings, which every serious build does.

An extractor is just an object with unapply(input): Option[Result] — returning Some means the pattern matched and the contents are bound, None means try the next case. That single convention makes pattern matching open: you can match on a parsed integer, a regex capture, a JSON shape, or a domain concept like case ValidEmail(user, host), and it reads as though the language knew about it. Kotlin's when is closed by comparison — it matches types, constants and boolean conditions, so any real parsing must be lifted out into a variable first, which is exactly what the left column has to do.

The head :: tail pattern is the reason recursive list code reads so cleanly in Scala, and it is the shape every functional-programming tutorial assumes you know. Kotlin can express the same recursion with first() and drop(1), but each call allocates a new list and nothing checks that you handled the empty case — the when is not exhaustive over a List, so an off-by-one is a runtime NoSuchElementException rather than a compile-time warning. The +: / :+ patterns match at either end, which is a nicety even most Scala developers forget exists.

One implicit val at the top, and every call below it that needs a Configuration gets one — including calls three layers down, which is where the hand-threading in the left column becomes genuinely painful (add a parameter to a leaf function and every caller in the chain changes). This is how Scala passes an ExecutionContext to every Future, a transaction to every query, and a logger to everything. Kotlin's nearest attempt is context receivers, still experimental after several redesigns. The cost is the one everybody warns you about: when the compiler cannot find an implicit, the error tells you a value is missing but not why the one you expected was not eligible — and Scala 3 renamed the whole thing to given/using partly to make that failure legible.

Same result, one extra layer of machinery: Scala reaches its extension methods through an implicit conversion to a wrapper class, and extends AnyVal is what lets the compiler erase that wrapper so nothing is allocated. The practical difference is scope — a Kotlin extension is visible wherever it is imported as a function, while a Scala implicit class must be in implicit scope, which usually means an explicit import Extensions._. Scala 3 replaces all of this with a first-class extension (text: String) def shout: String = …, which is essentially Kotlin's syntax arriving fifteen years later.

Look at what the compiler did with toJson(List(1, 2, 3)): it needed a JsonWriter[List[Int]], found listWriter, saw that it required a JsonWriter[Int], found intWriter, and assembled the instance — all at compile time, with the call site saying nothing. The Kotlin column has to build that same tree by hand (ListWriter(IntWriter)) at every use, and grows unmanageable for a nested type like Map<String, List<Int>>. That resolution is the reason Scala's library ecosystem looks the way it does: JSON codecs, ordering, equality, and the whole of Cats are type classes, and it is also the reason the compiler is slow and the error messages are what they are. Missing instance means a compile error, which is the good half of the bargain.

Kotlin took declaration-site variance from Scala and renamed the annotations: +A is out A, -A is in A, and the rules (a covariant parameter may only appear in output position, a contravariant one only in input position) are identical. Kotlin adds use-site variance too (Array<out Any> at a call site), which Scala expresses with existential types or bounds and generally avoids. The reason this matters more in Scala is that its collections are covariant by default — List[Cat] genuinely is a List[Animal], where Kotlin's List is covariant but MutableList cannot be.

A Kotlin type parameter always stands for a complete type, so F<_> is simply not writable and there is no way to say "any container that can be mapped over" — you write doubleList, doubleNullable, doubleSequence, and accept the duplication. (The Arrow library simulates higher kinds with a defunctionalization trick, and the boilerplate it costs is the argument for why this belongs in the language.) In Scala, F[_] plus implicits is the foundation everything functional is built on: Functor, Monad, Traverse and the rest of Cats are exactly this trait with more laws, which is what lets one traverse work over every effect type in your program.

Read the two yield blocks and notice that they are the same syntax doing two different things: over Option it is a chain of fallible steps that short-circuits on the first None; over List it is a nested loop with a filter. It works because both types have flatMap, and for is nothing but sugar for it — which means it works over Either, Try, Future, a database transaction, or any type you give a flatMap to. Kotlin has no such construct, so each container gets its own idiom: ?:-with-early-return for nullables, flatMap chains for lists, suspend for futures. That fragmentation is the concrete cost of not having the abstraction.

This is the payoff for the abstraction. The for block is structurally identical to the Option one on the previous row, but every failure now carries a typed message out with it, and the happy path still reads as three sequential lines. Kotlin's Result cannot do this: its error type is fixed to Throwable, it has no flatMap in the standard library, and there is no comprehension to chain it with — so the idiomatic Kotlin is the early-return ladder in the left column, which works but does not compose (you cannot pass that pipeline around as a value, or run a list of them and collect the failures). Arrow's Either and its either { } block exist precisely to import this pattern.

Three assumptions to unlearn. A Future is eager: constructing it submits the work, so there is no async { } to write and also no way to describe a computation without starting it. Nothing owns it — there is no coroutineScope, no structured concurrency, and no cancellation (you can drop the result; the work runs on). And the thread pool arrives as an implicit ExecutionContext, which is why that odd import …Implicits.global line appears in every Scala tutorial: it is putting an implicit value in scope for every Future below it to pick up. What Scala gets in exchange is that Future is an ordinary monad, so it composes with map, flatMap, and the for-comprehension you already know.

Both Scala blocks look the same and one of them is twice as slow. The for desugars to fetch(1).flatMap(first => fetch(2).map(…)), so fetch(2) is not even constructed until the first future completes — and because a Future starts on construction, that is the difference between running in parallel and running in sequence. The fix is to build the futures on their own lines first, which every Scala style guide teaches and every Scala codebase gets wrong somewhere. Kotlin cannot have this bug: a suspend call is sequential and looks it, and concurrency requires you to type async. Laziness is what makes the Scala version ambiguous, and it is the strongest argument in the language for effect systems like Cats Effect and ZIO, whose IO is lazy and therefore safe to sequence.

Try is Kotlin's Result with two additions that matter: it is a sealed type, so Success and Failure pattern-match and destructure like any other case class, and it has flatMap, so it works in a for-comprehension and composes with other fallible steps. Kotlin's Result deliberately does not — it cannot be a function's return type without a compiler flag, and it has no comprehension to chain it in. Both carry a Throwable rather than a typed error, which is why Either (previous section) is what you reach for when the failure is part of your domain rather than an exception.

Kotlin already made try an expression, so the shape carries over. What changes is catch: it takes a block of case clauses, which means the full pattern language applies — you can destructure the exception, guard on its contents, and match several types in one clause. Neither language has checked exceptions. The idiomatic advice in Scala is nevertheless to use Try or Either at your own boundaries and reserve throw for genuinely exceptional conditions and for talking to Java libraries, since an exception is invisible in a type signature and cannot be composed.