TypeScript.CodeCompared.To/Kotlin

Kotlin's val and var map directly onto TypeScript's const and let — the naming is even easier to remember, since "val" evokes "value" and "var" evokes "variable." Idiomatic Kotlin prefers val everywhere it can, exactly as idiomatic TypeScript prefers const.

Both languages infer the type of a variable from its initializer, and both fix that type permanently at declaration — TypeScript at compile time, Kotlin at compile time too, but Kotlin additionally carries the type into the compiled bytecode, so it stays enforced at runtime rather than being erased.

The annotation syntax is identical — a colon after the name. The meaningful difference is underneath: TypeScript's number is one type covering every numeric value, while Kotlin distinguishes Int, Long, Double, and Float as genuinely different runtime types with different memory layouts.

These look similar but behave very differently. TypeScript's any disables type checking entirely — a call to a nonexistent member compiles without complaint and only fails, often confusingly, if that line actually executes at runtime. Kotlin's Any is simply the root of the type hierarchy (comparable to unknown, not any): you can hold anything in it, but the compiler still requires a cast or type check before calling a member, so a typo like this is caught before the program ever runs.

This is the single biggest gap between the two languages. TypeScript's strict-null-checks is a compile-time-only discipline: it vanishes the moment the JavaScript runs, so as any, a loose external API, or a stale build can smuggle null/undefined straight through. Kotlin's String vs String? distinction is enforced by the compiler down to a real runtime guarantee — a non-nullable String genuinely cannot be null when the program is running, not just when it was type-checked.

The syntax ?. is identical in both languages and short-circuits the same way when the receiver is missing. The difference is what backs the guarantee: TypeScript's compiler tracks | undefined only in code it can see, and the check disappears from the emitted JavaScript, whereas Kotlin's ?. is checking a type that is genuinely part of the value's runtime representation.

Kotlin's Elvis operator ?: — named for its resemblance to an emoticon of Elvis Presley's hairstyle — behaves exactly like TypeScript's ??: it substitutes the right-hand side only when the left side is null, not for every falsy value the way || would. The two operators are a near-perfect syntactic match, just spelled differently.

TypeScript's ! non-null assertion is purely a compile-time annotation — it is erased entirely, so a wrong assertion just lets undefined flow through until something downstream throws an unrelated error. Kotlin's !! is a real runtime check: it throws a NullPointerException immediately at the assertion site if the value actually is null, which is far easier to debug but still considered a code smell — idiomatic Kotlin reaches for ?. and ?: instead.

The pattern reads almost identically — narrow with an if check, use the narrowed value directly inside the block. TypeScript's narrowing is a static analysis performed purely by the compiler over erased types; Kotlin's smart cast is the same kind of static analysis, but layered on top of a type that is also enforced at runtime, so the two guarantees reinforce each other instead of one being purely cosmetic.

TypeScript always requires backticks and ${} for every interpolation, even a bare variable. Kotlin allows a bare $name for a simple identifier and reserves the ${expression} braces for anything more complex — a small but frequent syntactic convenience, and it works inside ordinary double-quoted strings rather than needing a special delimiter.

Both languages support multiline string literals, but TypeScript template literals still process escape sequences, so a literal backslash needs doubling. Kotlin's triple-quoted strings are true raw strings — no escape processing at all — and pair with .trimIndent() to strip the common leading whitespace introduced by indenting the literal in source code.

The methods available are nearly a one-to-one match, with a handful of naming differences that trip up a TypeScript developer at first: lowercase()/uppercase() instead of toLowerCase()/toUpperCase(), and contains() instead of includes(). Both languages' strings are immutable — every method returns a new string.

Kotlin attaches conversion methods directly onto the string value instead of routing through global functions like parseInt. Where TypeScript's parseInt quietly returns NaN on unparseable input, Kotlin's toInt() throws a NumberFormatException — the safer alternative toIntOrNull() returns null instead, which then pairs naturally with the Elvis operator to supply a default.

A TypeScript readonly string[] only blocks mutation at compile time — the underlying JavaScript array is always mutable, so a cast or an untyped caller can still push onto it. Kotlin's List versus MutableList distinction is a genuinely different runtime type: listOf() produces an object that has no add() method to call in the first place.

Kotlin builds a key-value pair with the infix function to ("Alice" to 95), rather than a two-element array literal or object literal. Subscript syntax works both for reading (scores["Alice"], matching .get()) and writing (scores["Carol"] = 92, matching .set()). As with lists, mapOf() is read-only and mutableMapOf() opts into mutation.

The Kotlin Set API is a close match for TypeScript's Set, with in replacing .has() and remove() replacing .delete(). Kotlin additionally distinguishes ordering guarantees at the type level: LinkedHashSet (the default, insertion-ordered), TreeSet (sorted), and plain HashSet (no ordering, fastest).

This is one of the strongest bridge points between the two languages — filter, map, and find carry over almost unchanged. TypeScript's reduce(callback, initialValue) corresponds to Kotlin's fold(initialValue) { accumulator, element -> }, with the initial value moved to the front. Kotlin lambdas use trailing curly braces rather than parentheses, and a single implicit parameter is available as it.

TypeScript needs either a mutable let variable assigned in every branch of an if statement, or a ternary chain for a value-producing conditional. Kotlin's if is itself an expression that yields a value directly, which eliminates the ternary operator entirely — Kotlin has none — while staying just as concise as the statement form for side-effecting code.

TypeScript's switch is a statement with fall-through by default, requiring break on every branch and a separately declared, mutable variable to capture a result. Kotlin's when is an expression — each branch ends at -> with no fall-through and no break, and it can be assigned directly to a val. This is a much closer parallel to a TypeScript discriminated-union narrowing pattern than to a switch statement.

A subjectless when { } behaves like an if/else if chain, where each branch is an arbitrary boolean condition rather than a value to match. This is strictly more expressive than a TypeScript switch, which can only match discrete values or a discriminant — Kotlin's when subsumes both roles in one construct.

Kotlin's for (item in collection) maps directly onto TypeScript's for (const item of collection) — both iterate values rather than indices. Kotlin's .withIndex() is the equivalent of .entries(), destructuring to (index, value) pairs; note Kotlin's in here is unrelated to the membership-testing in operator used elsewhere.

Kotlin functions are declared with fun and place the return type after the parameter list with a colon, closely resembling a TypeScript function declaration's : ReturnType. Kotlin's single-expression shorthand (fun square(x: Int) = x * x) is the direct counterpart of a TypeScript implicit-return arrow function, but it also applies to named top-level functions, not just anonymous ones.

Default parameter values work the same way in both languages — trailing parameters with defaults may be omitted at the call site. The difference appears with named arguments (the next concept): Kotlin lets you skip a default anywhere in the parameter list by name, while TypeScript still requires an explicit undefined to skip over a middle default when calling positionally.

Kotlin has genuine named arguments as a language feature: any parameter may be specified by name, in any order, without wrapping everything in an options object. TypeScript developers reach for an options-object parameter — as in the anchor example — specifically to simulate what Kotlin already provides directly.

Kotlin's vararg keyword marks a parameter that accepts any number of arguments, matching TypeScript's rest parameter ...numbers. Both languages spread an existing array into the call with a prefix operator — TypeScript's ...values becomes Kotlin's *values. Unlike TypeScript, where the rest parameter must be last, Kotlin permits parameters after a vararg, provided they are supplied as named arguments.

Kotlin lambdas are written entirely inside curly braces, with the parameter list (if any) before ->, rather than TypeScript's (params) => body. When a Kotlin lambda has exactly one parameter and it is left unnamed, it is available as it — TypeScript has no equivalent shorthand and always requires naming the parameter.

When a Kotlin function's last parameter is a function type, the lambda argument can be moved outside the parentheses entirely — and if it is the only argument, the parentheses can be dropped altogether. TypeScript has no equivalent: a callback argument always stays inside the call's parentheses. This trailing-lambda convention is what makes Kotlin DSLs (like buildList { }) read like built-in syntax.

Kotlin's function type syntax, (ParameterType) -> ReturnType, closely mirrors TypeScript's (value: number) => number — the main difference is dropping the parameter names in the type position and using -> instead of =>. Both languages check the compatibility of a passed-in function against its declared type at compile time.

Kotlin closures capture and can mutate a var from their enclosing scope, exactly as JavaScript/TypeScript closures capture a mutable let. A captured val is read-only from inside the closure, mirroring how a captured const cannot be reassigned inside an arrow function.

TypeScript's constructor(public x: number, public y: number) {} shorthand for declaring-and-assigning fields already feels close to Kotlin, but Kotlin takes it further: the entire primary constructor lives in the class header, with no constructor keyword and no method body at all needed for simple cases. The new keyword is also gone — Point(0.0, 0.0) constructs directly.

TypeScript classes and their methods are extendable and overridable by default; the rarely-used final keyword closes that off. Kotlin inverts the default: every class and every method is implicitly final, and inheritance or overriding must be explicitly opted into with open. This favors composition over inheritance and prevents the accidental-subclassing bugs that an open-by-default language allows.

This is a genuine and easy-to-miss trap. TypeScript's interface is structural — any object with a matching shape satisfies it, with no declaration linking the two. Kotlin's interface is nominal — a class must explicitly declare : Speaker to satisfy it, even if its methods match exactly — and it can also carry default method implementations, which makes it closer in spirit to a TypeScript abstract class than to a TypeScript interface.

TypeScript's get accessor and Kotlin's property with a custom get() are conceptually the same feature — a value that is computed on read but accessed with plain property syntax, no parentheses. The syntax differs: TypeScript nests the accessor inside the class body next to a method-like get area(), while Kotlin declares the property type first and attaches get() beneath it.

TypeScript's interface and type exist purely at compile time — they vanish before the code runs, so there is no automatic structural equality at runtime, and === always compares object references. Kotlin's data class generates a real equals() (and hashCode() and toString()) from the constructor properties, so == performs genuine value comparison. Reproducing this in TypeScript requires hand-written comparison code or a library like lodash.isEqual.

TypeScript developers reach for object-spread ({ ...alice, age: 31 }) to build a modified copy, since there is no built-in method that does this automatically for a plain type. Kotlin's data class generates a copy() method for free, taking named-argument overrides for just the fields that changed — the equivalent of the spread pattern, but generated rather than hand-written and available on every data class without extra code.

TypeScript object destructuring matches by property name, so field order in the pattern does not matter. Kotlin data-class destructuring is positional — it calls the auto-generated component1(), component2(), and so on, in declaration order — so val (x, y) = point only works correctly if the pattern's order matches the constructor's order.

TypeScript has no true extension-function feature. Its closest analog, module augmentation of a global interface plus mutating String.prototype, is much weaker: it patches a single shared prototype for the entire program, cannot be scoped to one file, and risks colliding with other code doing the same thing. Kotlin extension functions are resolved statically at the call site and can be imported (and thus scoped) independently per file, with zero risk of a global collision.

Where TypeScript idiomatically reaches for a free function (area(rectangle)) to add behavior without touching the original type, Kotlin's extension function syntax, fun Rectangle.area(), lets the same free function be called with member syntax (rectangle.area()). It compiles down to a static function taking the receiver as its first argument — genuinely new syntax, not new dispatch behavior, but a real, first-class part of the language rather than a workaround.

This is the strongest direct parallel between the two languages. A TypeScript discriminated union closed over a literal kind tag corresponds almost exactly to a Kotlin sealed class hierarchy, and both give the compiler enough information to check exhaustiveness — TypeScript when a switch is checked against `never` in the default case, Kotlin automatically for any when used as an expression over a sealed type, with no extra code required.

TypeScript's exhaustiveness checking is a pattern the developer must opt into deliberately, typically the const exhaustiveCheck: never = value trick in a default case — omit it and an unhandled variant compiles silently. Kotlin's exhaustiveness check on a when expression over a sealed class is automatic and mandatory: the compiler itself refuses to compile a non-exhaustive when expression, with no idiom to remember or forget.

Kotlin's sealed interface lets unrelated classes implement a shared, closed hierarchy — useful when the variants are not naturally related by inheritance. This is functionally close to a TypeScript union of interfaces sharing a discriminant field, but Kotlin enforces the closed set at compile time: every implementing class must be known and visible to the compiler in the same module, whereas TypeScript's union is open to any type matching the shape unless deliberately restricted.

The surface syntax is a genuinely good bridge point: Kotlin's suspend fun reads much like an async function, and calling a suspend function inside a coroutine scope reads like calling an async function with await already applied — Kotlin has no separate await keyword because calling a suspend function implicitly suspends until the result is ready. The deeper difference is structural concurrency (the next concept): a JavaScript Promise starts running the instant it is created and nothing tracks whether anyone is still waiting on it, while Kotlin coroutines are owned by a scope that can cancel them as a group.

This is Kotlin's deepest advantage over promises: coroutineScope enforces structured concurrency, meaning every coroutine launched inside it is guaranteed to either complete or be cancelled before the scope itself returns — there is no way for a child coroutine to silently outlive its parent. JavaScript's Promise.all offers no such guarantee: if one promise rejects, the other keeps executing in the background with no owner and no way to cancel it, a class of resource leak that structured concurrency eliminates by construction.

TypeScript's try/catch is purely a statement, so recovering a value out of it requires declaring a mutable variable beforehand and assigning it in every branch. Kotlin's try/catch is an expression — the last expression evaluated in whichever block ran becomes the value of the whole try — which lets the result be bound directly to a val with no mutable intermediate.

TypeScript catches every error as unknown and requires an instanceof Error check before touching .message safely. Kotlin's runCatching { } sidesteps try/catch altogether by wrapping the block in a Result<T> value — either a success or a failure carrying the actual Throwable — with combinators like getOrElse and exceptionOrNull() to extract what you need without manual narrowing.

Both languages let you define a custom error type carrying extra data. Kotlin's primary-constructor syntax combines the field declaration, constructor parameter, and property access into one line (val shortfall: Double), where TypeScript needs a separate public readonly shortfall: number constructor parameter plus a call to super(). Kotlin also requires the caught exception's type to be stated explicitly in catch (error: InsufficientFundsException) — there is no untyped catch parameter the way TypeScript's catch (error) defaults to unknown.

A TypeScript programmer moving to Kotlin should expect !! to fail loudly and immediately: because Kotlin's null safety is real at runtime, asserting non-null on an actual null throws a NullPointerException at the exact line of the assertion, rather than letting an undefined silently propagate downstream the way an erased TypeScript ! would. This is more disruptive in the moment but far easier to debug — the stack trace points straight at the bad assumption.

A recurring surprise moving from TypeScript: Kotlin treats if, when, and try as expressions far more consistently than TypeScript treats if, switch, and try as statements. Code that needed a mutable variable declared up front and assigned inside each branch in TypeScript often collapses into a single expression in Kotlin — a difference in habit more than in individual syntax, but one that changes how idiomatic Kotlin code is structured throughout.

TypeScript's type system is fundamentally structural: any value with a matching shape satisfies an interface, with no declared relationship required. Kotlin is nominally typed throughout: a type only satisfies an interface if some class explicitly declares that it implements it. An object literal that happens to have an x and a y property does not satisfy a Kotlin Point interface — there is no anonymous-object equivalent of duck typing here.

TypeScript's get/set accessors exist too, but a plain public field and a getter/setter pair look visibly different at the declaration site. In Kotlin every val/var declared as a class member is technically a property with a default getter (and setter, for var) — replacing them with custom logic changes nothing about how the property is accessed from outside. A TypeScript programmer reading temperature.fahrenheit = 100.0 should not assume it is a simple field write; it might silently trigger arbitrary code.