Rust.CodeCompared.To/Kotlin

println! is a macro because it checks its format string at compile time; println is an ordinary function taking one value, and formatting is done by string interpolation instead. Semicolons are optional in Kotlin and nobody writes them. A Kotlin file may hold top-level functions, top-level properties and several classes with no relationship to its filename, so the file organization feels closer to a Rust module than to a Java one.

A data class generates a toString() printing the type name and every constructor property, which is what #[derive(Debug)] produces; a plain class prints its name and an identity hash, so a missing data shows up as Point@6d06d69c rather than as a compile error. Interpolation is $name for a bare name and ${expression} for anything else — note that the braces are the opposite way round from Rust's, where they are always required. Format specifiers do not live in the interpolation at all; "%.2f".format(value) is the equivalent of {:.2}. One thing to expect when you run this row here: the Kotlin cell renders with the red error styling, because the runner treats any output on stderr as a failure and this row writes to stderr on purpose. The output itself is correct.

You stop writing moves, borrows, lifetimes, clone() and & — an enormous amount of ceremony, and with it the entire category of "fighting the borrow checker". What you get in exchange is a program where any two references may point at the same mutable object and no tool will say so. Kotlin's mitigations are all conventions rather than proofs: val by default, data class with copy(), read-only collection interfaces, and — the strongest of them — the compiler's refusal to smart-cast a mutable property, which is the one place it admits that something might change underneath you.

use { } is an extension function on AutoCloseable that runs the block and calls close() in a finally, so it is drop scoped to a block — and it is a library function rather than syntax, which the trailing-lambda rule makes invisible. The gap is that nothing requires it: forgetting the use compiles fine and leaks the handle until a finaliser runs, if there is one at all. Memory itself needs no cleanup, so this only matters for files, sockets and native handles. Rust's guarantee is that drop runs and cannot be forgotten; Kotlin's is that close runs if you remember to ask.

A JVM cycle is collected as soon as nothing outside it is reachable, so a parent/child back-reference is two fields. WeakReference exists and is for caches rather than for breaking cycles. What you pay is that release is non-deterministic: you cannot say when memory comes back, allocation-heavy code produces collection pauses, and the explicit cost of Rc<RefCell<T>> is replaced by an implicit one that appears in a profiler rather than in the type. The RefCell half — a run-time borrow check — is simply not a concept here, because there are no borrows to check.

Rust's mut governs the value: let items makes the whole vector unmodifiable. Kotlin's val governs only the binding: val growable = mutableListOf(…) cannot be reassigned and can absolutely be added to. Deep immutability comes from choosing an immutable type instead, which is why Kotlin splits every collection into a read-only interface and a mutable one. The honest caveat is that List is a read-only view, not an immutable value — hand the same MutableList to two places and one can still change what the other sees, which & versus &mut would have prevented.

String? is a genuinely different type from String, and calling a method on one without handling the null case does not compile. The operators map one for one: ?. is map, ?: (Elvis) is unwrap_or, and !! is unwrap — it throws where Rust panics, and carries the same reviewer's eyebrow. Instead of binding a new name, Kotlin smart-casts: after if (name != null) the compiler narrows name itself, so there is no if let shadowing dance. Two things Option has that nullable types do not: it nests (Option<Option<T>> is meaningful, String?? is not), and it is a value you can put in a collection or map over generically.

The Elvis operator's right-hand side may be a return, a throw, or a break, because those are expressions of type Nothing — the empty type, which is a subtype of everything and therefore fits anywhere. That is exactly the role of Rust's !. The result is the same shape as let … else in about half the characters, and it is the single most common line in idiomatic Kotlin. ?.let { } is the other form, for when you want a block rather than an early exit.

A value from an unannotated Java method has a platform type, assignable to either String or String? with no complaint, so the check you skipped becomes a NullPointerException after all. The mitigations are real — Java libraries increasingly carry @Nullable/@NotNull annotations that Kotlin honors, and the habit is to declare the nullable type at the boundary and narrow at once. For a Rust reader the useful framing is that this is Kotlin's unsafe: a place where a guarantee is asserted rather than proved. The difference is that Rust makes you write the word.

Kotlin has no checked exceptions — a deliberate rejection of Java's design — so there is no throws clause and the compiler never asks you to handle anything. A function that can fail looks exactly like one that cannot. What Kotlin does keep is that try is an expression, so it produces a value and reads much like a match on a Result. An uncaught exception unwinds the thread and prints a stack trace, which is roughly what a panic does, except that a panic's default is to abort a thread you probably wanted alive and this one is caught by a framework somewhere up the stack.

It supports map, mapCatching, recover, getOrNull, getOrElse, getOrDefault, onSuccess and onFailure, which covers most of what Result gives you. Three real limitations. The error type is always Throwable — there is no E, so a typed error enum has to be modelled as a sealed class instead (the next section). It cannot be a function's declared return type without a compiler flag, because of a JVM signature clash, so it is used inside a function rather than across an API. And there is no ? operator, so propagation is manual. The caution to carry over: runCatching catches Throwable, cancellation included, so coroutine code must re-throw CancellationException.

This is Result<T, E> written out by hand, and it gets the property that matters: a when over a sealed type is checked for exhaustiveness at compile time, so adding a fourth case breaks every consumer that has not been updated. What it does not get is the ? operator, so a three-step fallible pipeline is three nested whens rather than three question marks — which is why teams reach for the Arrow library's Either and its bind(), or accept exceptions for the propagation and use sealed types only at boundaries.

There is no checked_add, no saturating_add and no debug-mode assertion; the closest thing is Math.addExact from the Java library, which throws ArithmeticException. In practice Kotlin code avoids the problem by using Long for anything that accumulates and BigInteger when it genuinely cannot bound the value. The type set is Byte, Short, Int, Long and their unsigned counterparts (UInt, ULong, still marked experimental in places), and — unlike Rust — there is no implicit widening either, so toLong() is written out.

A value class (formerly "inline class") with one property is erased at run time to the underlying type wherever the compiler can manage it, so Meters is usually just a double in the generated bytecode — which is the zero-cost story a Rust reader expects. The boxing does come back in three places worth knowing: when the value is used as a generic argument, when it is stored in a collection, and when it is nullable. And where Rust's orphan rules keep two crates from implementing the same trait for the same type, Kotlin has no coherence check at all: two libraries can define conflicting extension functions on the same type, and the one that wins is decided by which is imported.

A Kotlin typealias is file-level or top-level rather than scoped inside a function, and — like Rust's — it is purely a name, so nothing prevents a UserId from being passed where an OrderId is expected. That is what the value class in the previous row is for. Function types are written (Int) -> Int, which is the same arrow Rust uses, and referring to an existing function as a value needs ::double where Rust needs only the bare name.

() is Unit — a real type with exactly one value, printed as kotlin.Unit, and the implicit return of any function that does not say otherwise. ! is Nothing: the type with no values, the type of throw and of a function that never returns, and a subtype of everything, which is exactly what lets it appear on the right of an Elvis operator or in one arm of a when without disturbing the result type. Any is the top type and corresponds to dyn Any without the downcasting ceremony — note it is not nullable, so "anything at all including null" is Any?.

sealed means every direct subtype is declared in the same module and package, so the compiler knows the world is closed and checks the when for exhaustiveness: the code above has no else and compiles, and adding a fourth subtype turns every such when into a compile error. That is the same guarantee match gives you. A payload-free case is a data object, which is a singleton — Rust's unit variant. The differences are in representation and ergonomics: a Rust enum is one value the size of its largest variant while this is a separate heap object per case, and there is no destructuring in the when arm, so you write result.value after the smart cast rather than binding it in the pattern.

Priority.entries (which replaced values() in Kotlin 1.9) is the iteration, and there is no equivalent of Rust's cast to the discriminant — the numeric value is an ordinary property you declared, and ordinal gives the declaration index. valueOf("High") parses a name and throws on a miss, where entries.find { … } returns null. A when over an enum is exhaustiveness-checked exactly as over a sealed type, which is why label() above needs no else.

It comes in two forms: with a subject, when (value) { 0 -> …; in 1..9 -> …; is String -> … }, and without one, where each arm is a full boolean condition — which is the form used above and has no match counterpart, since Rust arms are patterns rather than conditions. Ranges use in 1..9 against Rust's 1..=9, and a guard becomes an ordinary && in the subject-less form. Exhaustiveness is required when the result is used as a value and the subject is sealed, an enum, or a Boolean; over an Int the else is mandatory, exactly as _ is in Rust.

Kotlin's destructuring is positional and driven by generated componentN() functions, so val (y, x) = point compiles and silently gives the wrong values, and reordering a data class's properties quietly breaks every destructuring of it — where a Rust struct pattern is by field name and cannot be transposed. There is also no way to destructure inside a when arm, no nested patterns, no @ bindings, and no or-patterns beyond comma-separated constants. The compensation is the smart cast: after is Success the arm can read result.value directly, which covers the common case if not the elegant one.

Two differences matter. A Kotlin interface must be implemented where the class is declared — there is no impl Greeter for String for a type you do not own — and the substitute is the next row. And override is mandatory on the implementing member, so a typo in a method name is a compile error rather than a method that is silently never called. Interfaces may declare properties as well as functions, may not hold state, and are multiply implementable, so the trait-as-capability style transfers directly. There is no equivalent of associated types; you use a generic parameter on the interface instead.

An extension function is resolved statically and compiles to a static method taking the receiver as its first argument — so it is not dynamic dispatch, cannot be overridden by a subclass, and loses to a real member method of the same name. That last point is the trap: adding a member with your extension's name silently changes what every call site does. What it buys is scoping: an extension is visible only where it is imported, so its blast radius is one file rather than one crate graph, which is a different and arguably better answer than the orphan rule to the same problem. There is no way to make a type satisfy an interface from outside, though — extensions add functions, not conformance — so impl ForeignTrait for MyType genuinely has no counterpart.

An interface-typed variable is Box<dyn Trait>: a reference plus a method table. There is no Box, because every object is already a reference, and no object-safety rules, because a JVM interface has no equivalent restriction. A generic function with an interface bound (fun <T : Shape> total(…)) looks like impl Trait and is not monomorphized — the JVM erases it to one compiled body — unless it is marked inline, which the generics section covers. Kotlin adds one thing Rust has no form of: class Service(logger: Logger) : Logger by logger generates every forwarding method automatically, so composition costs one line instead of one method per member.

There is no From/Into pair and no impl Into<T> parameter, so a function declares exactly the type it wants and callers convert first. The convention is an extension function named toX(), matching the standard library's toInt(), toList() and toString(). Two consequences: the conversion is visible at every call, which some people prefer, and there is no TryFrom either — a fallible conversion is a toXOrNull() returning a nullable, which is exactly the naming convention the collections section described. Kotlin also has no AsRef, and its nearest equivalent to a blanket impl is an extension on a generic receiver.

List<String> and List<Int> are the same class at run time, you cannot write T() to construct one, and value is T does not compile. Kotlin's answer is inline fun <reified T>: the function body is inlined at every call site with the type substituted in, so T::class and is T work — which is monomorphization, opt-in, one function at a time. That is also how filterIsInstance<String>() is possible. There is no PhantomData because an unused type parameter is simply allowed, and boxing is the other cost: a List<Int> holds boxed integers where a Vec<i32> holds machine words.

Kotlin's where clause goes after the parameter list and lists constraints as where T : A, T : B. What is missing relative to Rust is anything about layout or copying: there is no Copy, no Sized, no 'static, because every reference is the same size and the collector handles lifetime. Comparable<T> stands in for PartialOrd, and because Kotlin maps its comparison operators onto compareTo, item > result works on any Comparable without an extra bound. Variance is declaration-site — out T and in T on the type parameter — rather than Rust's inferred variance, and it is the one part of the section a Rust reader has to learn from scratch.

copy(label = "ink") is the struct-update syntax and takes named arguments for whatever you want changed, which is tidier than ..first.clone() and does the same job. The comparison operators are the thing to internalize: Kotlin's == calls equals and is therefore structural — matching PartialEq — while === is reference identity. That is the reverse of Java, where == compares references, and it is a deliberate fix. Note that copy is shallow: it copies the references, so a data class holding a MutableList shares that list with its copy, which is exactly the aliasing the ownership section warned about.

There is no static: a companion object is a singleton attached to the class, and its members are reached through the class name, so Parser.of(…) reads like Parser::new(…) while actually being a method on a real object that can implement interfaces. There is no self parameter either — the receiver is this and is nearly always implicit — and no &self/&mut self/self distinction, since there is no ownership to express. The other addition is properties: val length: Int get() = … looks like a field to every caller and is a getter, so you can start with a stored value and add computation later without changing a single call site.

A parameter may have a default expression — evaluated on every call, so the mutable-default trap cannot exist — and callers may name any argument and give them in any order. That covers what the builder pattern exists for, which is why Kotlin codebases have far fewer builders than the Java ones they replaced. Two things to watch: the parameter name is now part of the public interface, so renaming it breaks callers; and calling a defaulted function from Java requires @JvmOverloads, which generates the overload set, because the JVM has no notion of a default argument.

The names are ordinary words — plus, minus, times, get, contains, compareTo, invoke — marked with the operator keyword rather than declared through a separate trait, so there is no Output associated type and the return type is simply whatever you wrote. Implementing contains is what makes in work on your own type, and compareTo supplies all four comparison operators at once. The addition is infix: any single-argument method may be called without a dot or parentheses, which is where to, downTo, step and until come from — they are library functions, not syntax. The convention is to use it only where the result reads as English.

A Kotlin map's indexer returns V? rather than throwing, so ages["Bo"] is None spelled null and the get-returns-Option habit transfers exactly. The bigger idea is the read-only/mutable split: List, Map and Set have no mutating methods at all, and MutableList and friends do — so a function taking a List promises not to change it, which is a weak echo of & against &mut. Weak because it is a view: nothing prevents another holder of the same MutableList from changing it underneath. Mutating a collection while iterating it throws ConcurrentModificationException at run time, which is where Rust gives a compile error.

getOrPut(key) { default } is entry(key).or_insert_with(…), taking a lambda so the default is only built when needed. But the grouping itself is a single library call — groupBy { it.length } returns a Map<Int, List<String>> with the types worked out — and that pattern runs through the whole standard library: associate, partition, sumOf, maxByOrNull, chunked, windowed, zip, flatten. It is noticeably richer than Rust's std collections API, where the equivalent often means reaching for itertools.

IntArray, DoubleArray and the rest of that family compile to a JVM primitive array — the storage a Rust [i32; 4] or Vec<i32> has — while List<Int> holds boxed Integer objects, because generics are erased and a type argument must be a reference. So the specialized array types are what you reach for in numeric code, and they are deliberately awkward to encourage using List everywhere else. There is also no borrowed slice type: slice(1..2) copies, where &fixed[1..3] is a view with no allocation. That is one of the few places where the absence of borrows costs performance rather than only expressiveness.

Drop the asSequence() and the same chain builds a full intermediate list at every step — a million-element filtered list and then a million-element squared list, to take three values. Every operation on a Kotlin List is eager and returns a new list; laziness is opt-in through Sequence, which is the actual counterpart of Iterator. The rule of thumb the Kotlin documentation gives matches the cost model: for small collections the eager version is faster because it skips the per-element machinery, and for large ones or for early termination the sequence wins. sequence { yield(…) } is the builder form, and it is a coroutine underneath.

A function ending in OrNull returns null where its plain sibling throws, so maxOrNull() is max() returning Option and max() — where it exists — is max().unwrap(). The renames are small: filter, map, find, fold, zip, take, drop all match; flat_map is flatMap; chunks is chunked; windows is windowed; any/all/count match. it is the implicit single-parameter name, which is where most of the brevity comes from. There is no collect because an eager operation has already produced the list.

sequence { } is a suspend block in which yield suspends and hands a value to the consumer, so the state machine is generated rather than written — the thing Rust's unstable generator feature would provide. There is a matching yieldAll for delegating to another sequence. What you give up is control: you cannot implement size_hint, cannot provide a specialized count(), and cannot express ExactSizeIterator or DoubleEndedIterator. Implementing Iterator by hand is still available — an Iterable<T> with an iterator() method — and is what you write when the sequence needs to be re-iterable, since a sequence { } may be consumed only once.

Rust writes 'outer: for and break 'outer; Kotlin writes outer@ for and break@outer. What has no Rust counterpart is the second half: a bare return inside a lambda returns from the enclosing function, not from the lambda — a non-local return, legal only because forEach is inline — and return@forEach is what returns from the lambda itself, behaving like continue. Getting those two the wrong way round is a real and confusing bug, and it is the main reason to know that inline exists. Kotlin has no equivalent of Rust's loop { break value }, though a labeled run block gets close.

A Rust String is UTF-8 and len() is a byte count. A JVM String is UTF-16, and length counts 16-bit code units — so the flag emoji, one grapheme from two code points, is 8 bytes in UTF-8, 2 chars in Rust, and length == 4 in Kotlin, because each code point needs a surrogate pair. codePointCount gives the Rust chars() answer. There is no &str, so a substring allocates where &text[..3] does not — and there is also no possibility of the panic Rust gives you for slicing mid-character. buildString { } wraps a StringBuilder, since += in a loop allocates each time.

A bare name needs no braces ("$name") and anything more than a name does ("${name.length}"), which is the opposite of Rust's inline captures, where the braces are always there. Because the raw form still interpolates, a literal dollar sign inside one needs ${'$'} — the one genuinely ugly corner. Indentation is not stripped automatically; .trimIndent() removes the common leading whitespace and appears on essentially every multi-line literal. There is no compile-time check on interpolation the way println! checks its format string, because there is no format string.

Fn, FnMut and FnOnce collapse into (Int) -> Int. There is no move keyword and no capture-by-value: a Kotlin closure captures the variable, so a captured var can be read and written by the closure and by the enclosing scope alike — which is FnMut with no borrow checker and no RefCell. The last Rust example above simply has no counterpart, because nothing is ever moved. A single-parameter lambda can leave its parameter unnamed and call it it, which is where most of Kotlin's brevity comes from, and a lambda may contain as many statements as it likes with the last expression as its value.

run, repeat, use, runBlocking, buildString and every Gradle build script are ordinary function calls dressed up by it. The inline keyword is the other half and matters to a performance-minded reader: it inlines the function body and the lambda at the call site, so there is no function object allocated and no virtual call — which is what makes filter { } and map { } cost roughly what a hand-written loop costs, and is the closest thing Kotlin has to Rust's zero-cost closures. It also enables reified type parameters and lets a return inside the lambda return from the enclosing function.

A suspend function is called exactly like an ordinary one, and the compiler enforces only that the caller is itself suspend or is inside a coroutine builder. That removes the .await noise and makes turning a plain function into a suspending one a one-word change rather than a cascade — at the cost that you cannot tell from a call whether it suspends. There is no executor to choose or thread through: the runtime supplies dispatchers, so #[tokio::main] becomes runBlocking and nothing is generic over the runtime. Coroutines are also hot in the sense that matters: calling a suspend function runs it, and there is no inert value to poll.

A coroutineScope does not return until every coroutine launched inside it has finished, and if any of them fails — or if the scope body throws — the rest are cancelled automatically. There is no way to start a coroutine that outlives its scope by accident, which is exactly the tokio::spawn hazard where a dropped JoinHandle leaves a task running unobserved. Cancellation itself is cooperative rather than by drop: every suspension point checks, and a tight computational loop must call yield() or check isActive or it will not stop. That is more predictable than Rust's cancel-at-any-await-point, which is a known source of bugs where a future is dropped between two operations that had to happen together.

There is no Send and no Sync: any object may be touched from any thread, and no marker trait, no compiler check and no lint stands between you and a data race. The lock is also not attached to the data — padlock.withLock { } guards a region of code by convention, where Mutex<T> makes the data unreachable without acquiring it, and that design difference is the one to carry away. Arc disappears because every reference is shared and the collector handles the count. What Kotlin offers instead is a good library — Mutex, Channel, AtomicInteger, immutable data classes, confining state to a single coroutine — and none of it is a proof.

A Flow is a cold asynchronous stream — nothing runs until something collects it, which is precisely the relationship a Rust future has to its executor — with a large operator library attached: map, filter, debounce, combine, flatMapLatest, where the Rust equivalent means futures::Stream plus StreamExt from a crate. StateFlow and SharedFlow are the hot variants and are what an Android view model exposes. Channel maps to mpsc closely, including a bounded form, and differs in one familiar way: sending a value does not move it, so nothing stops you from continuing to use what you sent.

Dispatchers.Default is a pool sized to the core count and is for CPU work; Dispatchers.IO is a much larger elastic pool for blocking calls and is spawn_blocking; Dispatchers.Main is the Android or Swing interface thread and has no Rust counterpart at all. withContext(dispatcher) { … } moves a block onto one and moves back when it finishes, which is a thing tokio has no single expression for. The rule is the same as Rust's and matters as much: blocking a dispatcher thread — a Thread.sleep, a synchronous file read, a JDBC call — starves every coroutine queued behind it. The parallel-iterator role that Rayon fills is played by launching coroutines on Dispatchers.Default.

let passes the receiver as it and returns the block's value, so value?.let { … } is "do this only if it is not null" — if let Some(x), with it smart-cast to the non-null type. also passes it as well but returns the receiver, so it slots into a chain without changing its value, which makes it the natural home for logging and assertions in the middle of a pipeline. The distinction between all five reduces to two questions: is the receiver it or this, and is the result the block or the receiver. Rust's closest analogue is Option::map and the inspect adapters, which cover a fraction of the same ground.

Inside the block, this is the new object, so its properties are addressed by bare name and the repeated request. prefix disappears; the block returns the receiver, so the whole thing is one expression and can be assigned, returned, or passed as an argument. That is why Kotlin needs the builder pattern so much less than Java did, and it is a different answer from Rust's, which is a ..Default::default() struct literal or a chain of with_ methods returning Self. The Kotlin version works on a mutable object, which the ownership section already warned is the trade being made everywhere on this page.

The build file is itself a Kotlin program, which is why it reads as a sequence of trailing-lambda blocks and why an IDE can complete it — and also why a cold build downloads a great deal, takes minutes, and fails in ways that are considerably harder to reason about than a cargo build that went wrong. The Gradle daemon holds memory between builds to make later ones fast. Two concrete losses against Cargo: dependency locking is opt-in, so a default project does not have reproducible builds, and there is no cargo fmt/clippy equivalent in the box — ktlint, detekt and the IDE formatter are separate choices. The wrapper script ./gradlew pins the build tool's own version, which is one thing it does better than Cargo.

Kotlin has public (the default — the reverse of Rust's private-by-default), private, protected, and internal, which means visible within the compilation module and is roughly pub(crate). There is no pub(super) or pub(in path), and packages do not nest as a visibility hierarchy the way modules do — billing and billing.tax are unrelated names sharing a prefix. Nothing executes at import time, so there are no import-time side effects and no circular-import problem. A file may hold several top-level classes and need not be named after any of them, which makes a file feel like a Rust module even though the package is what actually scopes things.

The visibility consequence is the one to know: a Rust test module is a child module and can see private items, while a Kotlin test class is in a different file and sees only what its visibility allows — though because tests are in the same compilation module by default, internal members are visible and private ones are not. Assertion arguments are expected-then-actual, the reverse of what most people guess, and there is no assert_eq!-style diff output; assertEquals reports both values. The pleasant part is the backtick-quoted function name, which lets a test read as a sentence. Kotest is the popular alternative and MockK is the mocking library.

data class is a built-in derive and the only one; you cannot write your own. An annotation is metadata that does nothing by itself and is read either by reflection at run time or by a build-time processor — KSP (Kotlin Symbol Processing), which is the closest thing to a procedural macro and is what Room, Dagger and kotlinx.serialization use. Like a source generator it can only add files, never rewrite what you wrote. inline is a compiler transform on a function body and is what makes reified type parameters and non-local returns possible, but it substitutes code rather than manipulating syntax, so there is no macro_rules! equivalent anywhere in the language.