Kotlin.CodeCompared.To/Dart

Almost the same program. Three small things to retrain: the entry point is void main() rather than fun main(), semicolons are mandatory, and the house indent is two spaces rather than four. Single quotes are the idiomatic Dart string — double quotes work identically, and the linter will nudge you toward single.

final is Kotlin's val exactly: assigned once, at run time. const is the one that has no real Kotlin counterpart — Kotlin's const val is limited to primitives and strings, while Dart's const builds whole objects at compile time, deeply immutable and canonicalized (two identical const values are the same object). That sounds academic until you reach Flutter, where const widgets are the single biggest rebuild optimization there is — the framework can skip a subtree entirely because it knows the object is identical. Note also the naming: Dart constants are lowerCamelCase, not SCREAMING_CASE.

This one is free: same $name, same ${expression}, same triple-quoted multi-line strings. The one thing missing is trimIndent() — Dart keeps every leading space in a multi-line literal, so either left-align the content against the margin (ugly, and what most code does) or trim it yourself. Adjacent string literals concatenate automatically, which is a small C-inherited nicety Kotlin does not have.

The translation is nearly one-to-one: ?. is unchanged, ?: becomes ??, !! becomes a single !, and smart casts are called "type promotion" but behave the same. Dart's null safety is sound, meaning the compiler can prove a non-nullable variable is never null and the runtime can then optimize on that basis — and unlike Kotlin, there is no platform-type hole, because there is no Java interop to punch one. The bonus operator is ??=, which assigns only when the target is null.

late is lateinit without the restrictions — it works on int, double, bool, and any other type, where lateinit excludes primitives. It also absorbs a second Kotlin feature: a late final field with an initializer is lazy, so it replaces by lazy { } as well. Both share the same hazard — reading before assignment is a runtime error (LateInitializationError), not a compile error, so late is you telling the compiler to trust you.

Dart has no scope functions — no let, apply, also, run, or with — because it has no lambdas with receivers to build them from. In practice that costs less than it does in Java: type promotion means a plain if (name != null) block sees a non-nullable value, which is what ?.let was mostly buying you. For collections, whereType<String>() is filterNotNull(), and mapNotNull decomposes into a map followed by a whereType.

The => body is Kotlin's = expression under a different sigil, and it carries an implicit return just the same. Two things move: the return type goes to the front (C-style, not : Int at the end), and it is not inferred for a named function — you write int or void or String every time. Inference is reserved for locals and for closures.

The call site looks familiar but the rules are stricter: a parameter is nameable only if it was declared inside { }, and a positional parameter can never be passed by name. Named parameters are optional unless marked required, which is the keyword you will type more than any other in Flutter — Text('hi', style: …), Padding(padding: …, child: …), and every other widget constructor is a wall of named arguments. The third form, optional positional in [ ], has no Kotlin counterpart at all.

No vararg, no exceptions — the caller writes a list literal. The cost is two brackets per call; the compensation is the spread operator ..., which works inside any collection literal (not just at a call site) and is far more useful than Kotlin's *. There is also a null-aware spread, ...?, which contributes nothing if the operand is null — an idiom you will use constantly when building Flutter child lists.

The vocabulary shifts — filter is where, joinToString is join, sumOf is a fold — and the ergonomics take three real hits. There is no it, so every closure names its parameter. The core library is much thinner than kotlin.collections: no groupBy, no associateBy, no chunked, no zip — those live in package:collection, a first-party package you add to pubspec.yaml, and every real Dart project does. And fold needs its type argument written out: leave off the <int> and the accumulator infers as Object?, which fails to compile on the very next line with an error that points at the + rather than at the missing annotation.

Kotlin's nearest equivalent is buildList { }, which is a lambda with a receiver and a pile of add calls; Dart makes conditional and repeated elements part of the literal syntax itself. It reads better, and in Flutter it is essential: a widget's children: list is written exactly this way — if (isLoading) Spinner(), for (final item in items) ItemTile(item) — so the whole UI tree stays one declarative expression rather than a procedural build-up.

Dart's Iterable is Kotlin's Sequence: map and where are lazy, and the trace above interleaves with the mapping and stops after two elements. There is no eager mode, so asSequence() has no counterpart — and the flip side is the trap: forget the trailing .toList() and you are holding a recipe rather than a result, which will re-run its closure every single time you iterate it. A lazy Iterable that reads a file or hits a counter will surprise you.

There is no primary constructor, so fields are declared and then filled by initializing formals (this.x in the parameter list) — more typing than Kotlin's header, less than Java's. What you gain is two things Kotlin lacks: named constructors (Point.square(3), rather than an overload or a companion factory), and const constructors, which build the object at compile time and canonicalize it — note that the two Point.origin() values above are literally the same object. That last property is what makes const widgets free to rebuild in Flutter.

Miss the == override and every comparison silently falls back to identity; miss hashCode and your objects behave correctly in a list but duplicate themselves in a Set or a Map key. This is why essentially every serious Flutter codebase runs a code generator — freezed is the standard one, and build_runner regenerates the ==, hashCode, toString and copyWith you would otherwise hand-write. Note the shape of copyWith: it works by taking every field as a nullable named parameter and falling back with ??, which means it cannot distinguish "leave it alone" from "set it to null" — a real limitation Kotlin's copy() does not have.

A record is a value: structurally typed, equal by content, destructurable, and free of any declaration. That makes it strictly better than Pair/Triple — the fields can have names, so range.low beats range.first — and it is the right answer for multiple return values. What it is not is a replacement for a data class: a record has no name, no methods, no constructor validation, and no way to distinguish two records that happen to have the same shape. Use records for transient tuples, and hand-written (or generated) classes for anything with an identity in your domain.

There are no visibility keywords at all: a leading underscore makes a declaration private to its library, which by default means its file. So _count is not private to the class — anything else in the same file can reach it — and Dart has nothing corresponding to protected. The underscore is part of the name, so making a field private is a rename, and every reference changes with it. On the upside, the same mechanism works on top-level functions, classes, and variables, which is roughly Kotlin's internal.

The guarantee is the same one: sealed tells the compiler the complete set of subtypes, so a switch that misses one stops compiling. Two differences favor Dart. Object patterns destructure while they match — Card(number: final number) binds the field in the same breath as the type test, where Kotlin's is Card smart-casts but still makes you write payment.number. And when guards attach to a case (note the reversal: Kotlin's when is the whole construct, Dart's when is the guard clause). Sealed subtypes must live in the same library — the same file, in practice — which matches how you would organize them anyway.

Kotlin's destructuring is a convention — component1(), component2() — which is why it works on data classes and pairs but never on a List. Dart's is a real pattern language, so lists destructure with a rest element, maps destructure by key, and if (value case pattern) tests and binds in one step. The map pattern in particular is the one you will reach for daily: it is the difference between validating a decoded JSON blob field by field and matching its shape in a single expression.

Enhanced enums carry constructors, fields and methods just as Kotlin's do, and the mapping is direct: entries becomes values, valueOf becomes values.byName, and ordinal becomes index. The one difference in Dart's favor is that the constants are lowerCamelCase and each enum value is automatically a const, so it costs nothing to use one as a widget key or a map key. Enums are exhaustively switchable without a default, exactly like a sealed class.

Same feature, same static dispatch, same caveat that it cannot override a real method — the only visible change is that the extension block gets a name (Shouting), which exists so you can resolve conflicts and hide or show it in an import. Extension getters cover Kotlin's extension properties. Dart also has extension type (3.3+), a zero-cost wrapper around an existing type, which is closer to Kotlin's value class than to anything in this example.

The differences that matter: a mixin can carry fields, where a Kotlin interface with a default method cannot hold state at all; and the on clause constrains where a mixin may be applied, letting it call methods of the class it is mixed into. Multiple mixins are applied left to right and later ones win, which is a linearization rule you have to actually know. In Flutter you will meet this immediately — with SingleTickerProviderStateMixin on an animated widget's state class is the canonical example, and it works precisely because the mixin holds the ticker state for you.

A Future is Deferred and Future.wait is awaitAll, but three assumptions break. There is no dispatcher and no thread pool: Dart runs your code on a single event-loop thread, so await yields to the loop and nothing ever runs in parallel — Dispatchers.Default has no counterpart, and CPU-bound work will freeze the UI no matter how many futures you create. Calling an async function starts it at once, so there is no lazy async and no structured concurrency: nothing owns the work, and nothing cancels it. And a Future genuinely cannot be canceled — you can ignore its result, but the work runs to completion.

Stream is Flow: lazy, asynchronous, and built with async*/yield where Kotlin uses flow { emit() }. Consuming it with await for is nicer than collect { } — it is an ordinary loop, so break, continue and return all mean what they say, where a collect lambda cannot break out. The distinction to carry over is cold versus hot: a plain Stream is cold and single-subscription (listening twice throws), while a StreamController.broadcast() is the hot, multi-listener kind — roughly Kotlin's SharedFlow.

An isolate is a thread with no shared heap: it has its own memory and its own event loop, and everything crossing the boundary is copied (or transferred, for a TransferableTypedData). So there are no data races, no @Volatile, no Mutex, and no synchronized — the entire category of bug is gone by construction, and so is the entire category of solution. The cost is real: you cannot hand an isolate a reference to your object graph, and the copy is O(size). The rule of thumb in Flutter is that async is for waiting (I/O, network) and Isolate.run is for computing — parsing a large JSON payload on the main isolate is what drops your frames.

The mechanics are close, with two wrinkles. Catching by type uses on, and a bare catch takes an optional second parameter — the StackTrace — which is how you avoid losing it when rethrowing (use rethrow, not throw error). And like Kotlin, Dart has no checked exceptions; unlike Kotlin, it has no try-expression and no runCatching, so a fallback becomes a statement or a helper. int.tryParse is toIntOrNull, and the null-returning family is the idiomatic escape hatch.

This is a genuine trap on the way over. Kotlin's require throws in every build; Dart's assert is stripped from release builds, so a validation you wrote as an assert silently stops running the moment you ship. Use assert for invariants you are documenting to yourself and to the debug-mode framework (Flutter's own widgets are full of them), and throw an ArgumentError or StateError explicitly for anything a user's data could actually violate.

Four things to internalize. A widget is an immutable description that Flutter throws away and rebuilds constantly — it is not the thing on screen, so building one is cheap and you should never try to hold or mutate it. Layout is composed by nesting rather than by a Modifier chain: Modifier.padding(16.dp) becomes a Padding widget wrapped around the child, which is why Flutter trees are so deeply indented. A widget takes exactly one child or a list of children, and everything is a named argument. And const on a widget is not decoration — a const subtree is canonicalized, so Flutter can skip rebuilding it entirely.

The two-class split is the price of the widget being immutable: Counter is rebuilt from scratch each frame, so the mutable count has to live in _CounterState, which Flutter keeps alive across rebuilds. That State object is remember. The trap Compose does not have: setState is not automatic. Compose observes a MutableState and recomposes when you write to it, whereas Flutter only rebuilds when you explicitly say so — assign to count without wrapping it in setState and the field really does change while the screen keeps showing the old number, with no error anywhere. Beyond this, both ecosystems push you toward hoisting state out of the widget entirely (Riverpod or Bloc, against ViewModel and StateFlow).

Compose's LazyColumn takes a DSL where item { } and items(list) { } are calls in a builder scope; Flutter has no lambda-with-receiver, so laziness is expressed as a constructor that takes an itemCount and an itemBuilder callback. Notice what that costs: the index arithmetic above is manual, because there is no way to declare heterogeneous sections. When the list is short and static, the children: + collection-if/for form from the Collections section reads far better; reach for .builder when the list is long or unbounded.

One Compose construct becomes three lifecycle overrides, and the difference is not just verbosity. LaunchedEffect(userId) is keyed: it re-runs when the key changes and its coroutine is canceled when the composable leaves the tree, which is structured concurrency doing real work for you. Flutter has no such scope — initState fires once, didUpdateWidget is where you notice the key changed, and a Future cannot be canceled at all. Hence the if (!mounted) return; line, which is the single most important idiom in this example: without it, an async result arriving after the user has navigated away calls setState on a dead State and throws. Every Flutter developer has shipped that bug.