Kotlin.CodeCompared.To/Rust

The exclamation mark matters: println! is a macro, not a function — it expands at compile time so the format string can be checked against its arguments before the program ever runs. Rust programs also start at fn main(); the examples on this page show just the body.

Both languages make immutability the shorter spelling and mutation the deliberate choice. Rust goes further: mut is part of how the compiler reasons about the whole program — as the ownership section shows, who may mutate what is checked across function boundaries, not just at the declaration.

Inference feels the same day to day, with two differences underneath. Rust's numeric menu is wider — i8 through i128, unsigned u* types, f32/f64 — where Kotlin mostly lives on Int/Long/Double. And Rust's inference flows backward from usage: a later line can determine an earlier binding's type, which is why you will sometimes see turbofish annotations like collect::<Vec<i32>>().

Rust's format strings capture plain variables inline — {name} reads like Kotlin's $name — but arbitrary expressions go in trailing arguments filling empty {} slots, where Kotlin embeds them directly with ${…}. The macro checks every placeholder against its argument at compile time.

Run the Kotlin side and see [1, 2, 3, 4] — first observed a mutation made through second, because they alias the same heap object. Rust rules that entire class of surprise out: exactly one owner exists at a time, the compiler knows who it is, and it frees the memory the moment the owner goes out of scope. No garbage collector, no pause, no aliasing bugs — paid for by the discipline the next three concepts introduce.

Without the &, calling total_of(numbers) would move the vector into the function and the final println! would not compile. Kotlin passes every object "by reference" implicitly; Rust makes the loan explicit at both the call site and the signature, so you can always see whether a function takes ownership or just looks.

Many readers or one writer, never both — checked at compile time. This is the rule that makes "iterator invalidation" (mutating a collection while looping over it, Kotlin's ConcurrentModificationException) a compile error instead of a runtime crash, and it is the same rule that later makes data races impossible across threads.

Cheap scalar types (i32, f64, bool, char) are Copy and duplicate automatically on assignment — which is why the earlier move examples used a Vec, not an integer. Everything heap-owning moves unless you clone(). The visible call is the point: every allocation-costing copy in a Rust codebase can be found with a text search.

The translation table: ?. is .map(…), the elvis operator ?: is .unwrap_or(…), and ?.let { } chains are and_then. Because Option is just an enum, everything pattern matching can do applies to it — no special operators required, though the combinators read almost identically to Kotlin's.

Same shape, different mechanism: Kotlin's flow analysis retypes the same name, while if let Some(value) introduces a new name bound to the unwrapped contents. The Rust version generalizes to any enum, not just Option — if let is just a one-armed match.

The cultural difference is what code review says. A !! in Kotlin raises eyebrows; an unwrap() in production Rust often does too, with .expect("reason it cannot be None") as the self-documenting version. In examples and tests both are routine.

The {:?} format specifier prints via the derived Debug implementation — that is Rust's toString() for development output. The derive list is the data-class feature set unbundled, which means a struct can have exactly the capabilities it should: skip PartialEq and nobody can accidentally compare two values that have no meaningful equality.

Rust's ..person spread fills the remaining fields from an existing value. The ownership rules apply here too: a plain ..person would move the String field out of person, so this example clones — one more place where what Kotlin does implicitly (share the reference) becomes a visible decision.

Where Kotlin's when needs is checks and smart casts to reach each subclass's fields, Rust's match destructures the variant's payload directly into names. Both compilers enforce exhaustiveness over the closed set — add a Triangle and every match/when in the codebase becomes a compile error until handled. Option and Result are exactly this construct, from the standard library.

Both are expressions that return a value, both demand a case for everything (else / _). Rust's match works on patterns with if guards, so it destructures while it branches; Kotlin's subjectless when is closer to an if-else chain. Ranges work in both: Kotlin's in 1..9 is Rust's 1..=9.

Rust has no = expression short form because it does not need one: a block's final expression — no return, no semicolon — is its value. The semicolon rule is real and bites: adding one to first + second; turns the body into a statement returning (), and the function no longer compiles. return exists for early exits only.

Rust's substitutes are Option parameters (shown here), separate constructor functions, or — for anything complex — the builder pattern, which is what Kotlin's named-and-defaulted constructors were designed to replace. It is a real ergonomic regression from Kotlin, accepted for the sake of keeping every call site explicit.

There is no implicit it — Rust closures always name their parameters. Capturing multiplier works as in Kotlin, but the compiler classifies every closure by what it does with its captures (borrow, mutably borrow, or take ownership — the move keyword forces the last, as the threads section shows). Also note collect(): the map is not a list until you ask for one, which the collections section makes a headline.

More ceremony, one payoff: because the method arrives through a named trait, a reader can always answer "where did .shout() come from?" — it is whatever Shout implementation is in scope, and removing the use removes the method. Kotlin's extension imports work similarly but the declaration side is a single function with no interface to point to.

The working rule: functions accept &str (any string-ish thing can be lent as one) and produce String (the caller gets ownership). A &String coerces to &str automatically, so in practice you convert with String::from(…) or .to_string() going one way and & going the other. Every Kotlin String was secretly playing both roles; Rust names them.

A let mut String plus push_str is Kotlin's StringBuilder/buildString — except it is just the ordinary string type; no separate builder class exists because mutation is already opt-in. format! is the general-purpose combiner and returns a fresh owned String.

Watch the numbers: Kotlin reports length 5 (UTF-16 units), Rust's len() says 6 (é is two UTF-8 bytes) and chars().count() says 5. Rust refuses to pretend byte positions are character positions, so "give me character 1" must go through chars() — honest about the O(n) cost that Kotlin's indexing hides and sometimes gets wrong (surrogate pairs split the same way in UTF-16).

Kotlin distinguishes read-only and mutable at the interface level (List vs MutableList — and the read-only one is famously just a view). Rust has one Vec, and the binding's mut decides everything, checked at compile time: there is no way to hold a "read-only view" that someone else mutates behind your back, because the borrow rules forbid exactly that.

Rust's chain allocates no intermediate collections — elements stream one at a time through the whole pipeline, which the optimizer typically compiles down to a plain loop. Kotlin gets the same behavior only when you opt in with asSequence(). So the mapping is: Kotlin collections ↔ nothing in Rust; Kotlin Sequence ↔ Rust iterators, and Rust makes the lazy one the default.

Kotlin's map[key] returns a nullable; Rust's get returns Option<&V> — same idea, plus a borrow: the map still owns the value, you get a reference. .copied() turns Option<&i32> into Option<i32> for cheap types. There is no hashMapOf(…)-style literal in std; HashMap::from([("Ada", 36)]) is the closest.

The table to memorize: Kotlin 1..5 = Rust 1..=5; Kotlin 1 until 5 = Rust 1..5. Rust ranges cannot count down on their own — 10..6 is just empty — so descending iteration is an ascending range reversed. Slices use the exclusive form (&items[1..3]), which is why Rust made exclusive the shorter spelling.

The failure is in the signature — Result<f64, String> — so forgetting to handle it is a compiler warning, not a 2 a.m. stack trace. Kotlin's runCatching { } returning kotlin.Result is the same idea bolted on afterward; in Rust it is the only channel, and the whole ecosystem's errors compose because of it.

That single ? after parse() is the whole propagation story: on Err it returns early with the error, on Ok it evaluates to the inner value. Unlike an uncaught exception, the propagation is visible at every call site and in every signature along the way — grep "\?" shows you every path an error can travel.

The dividing line Kotlin blurs, Rust draws hard: expected failure (bad input, missing file) is a Result; an impossible state (broken invariant, out-of-bounds index) panics and unwinds. There is no try/catch for panics in normal code — a panicking thread dies. Kotlin's check/require preconditions are the same instinct, but they throw ordinary catchable exceptions.

The separation is the superpower Kotlin's extension functions only approximate: implementing Speaker for a third-party type, or a third-party trait for your type, is ordinary Rust. Traits can carry default method bodies like Kotlin interfaces, and struct Dog; — no fields, no constructor call parentheses — is a zero-sized type.

Kotlin's <T : Comparable<T>> is Rust's <T: PartialOrd> — trait bounds instead of upper bounds, with + stacking several. The extra Copy bound is ownership showing up in generics: returning T by value from a borrowed slice requires that T be copyable. Rust generics also monomorphize (a specialized copy per concrete type, like C++ templates) rather than erasing to Object as the JVM does — zero boxing, zero virtual dispatch.

On the JVM every object already lives behind a pointer with a vtable, so polymorphism has no visible cost. Rust's default is the opposite (values inline, calls static), so dynamic dispatch is spelled out: dyn Shape is the vtable, Box is the heap allocation. When all elements are one type, skip both and get devirtualized, inlined calls — the choice Kotlin never offers.

Kotlin destructures by position through generated componentN() functions — reorder the data class's fields and every destructuring silently changes meaning. Rust struct patterns bind by field name (Point { x, y }), immune to reordering; only tuples are positional. Patterns also nest arbitrarily deep, in let, match, function parameters, and loops.

Both keep the happy path unindented: bind it or bail. The Rust form works with any refutable pattern, not just Option — let Ok(value) = … else, let [first, ..] = … else — and the else block must diverge (return, break, panic), which the compiler checks.

The move keyword is the ownership system reaching into concurrency: the thread takes limit with it, so there is no question of the main thread mutating something the worker is reading. (Coroutines are Kotlin's real concurrency story, but they are a library; this compares the language-level primitives. Rust's async is likewise a separate, runtime-backed world.)

The difference is what happens when you get it wrong. Forget the AtomicInteger in Kotlin and you have a data race that tests may never catch. Forget the Mutex in Rust and the program does not compile — the Send/Sync marker traits encode thread safety in the type system, so "fearless concurrency" is a checked property, not a slogan. The lock also releases automatically when guard drops: RAII, next section.

This is RAII, and it is ownership's quiet payoff: files, sockets, locks, and memory all release at a known line — the end of the owner's scope — with no use block to remember and no GC finalizer running who-knows-when. The mutex guard in the previous example unlocked exactly this way. Forgetting cleanup is not a bug you can write.