Swift.CodeCompared.To/Rust

The exclamation mark is the first thing to notice: println! is a macro, not a function, so the format string is checked against its arguments at compile time. Rust programs start at fn main(), and the examples on this page show just its body — Swift, uniquely among compiled languages, lets top-level statements be the program, so the left column needs no wrapper either.

Immutable by default in both, which is one of the many places these two languages agree. The new habit is shadowing: re-declaring a name with let creates a fresh binding that may have a different type, which Rust programmers use constantly to convert a value through a pipeline (let input = input.trim(); let input: u32 = input.parse()?;) without inventing three names. Swift has nothing like it — a second let input in the same scope is an error.

Two Swift conveniences are simply gone. There are no argument labels, so a call is positional and connect(host, 8080, true) tells the reader nothing (the community answer is a builder or an options struct — the same pattern Java reaches for). And there are no default arguments, so you write the extra function. What Rust gives back is the expression-oriented body: the final expression without a semicolon is the return value, and a stray semicolon turns it into a statement returning () — which is the confusing early compile error you will hit within an hour.

This is the line where the two languages part company, and everything else in Rust follows from it. A value has exactly one owner; assignment (and passing to a function, and returning) transfers that ownership, and using the old name afterwards is a compile error. Swift reaches the same safety by copying value types and reference-counting the rest, at run time. Rust does it by proving ownership at compile time — so the buffer is freed exactly once, at exactly the point the owner goes out of scope, with no retain, no release, no atomic, and no deferred cost. What it takes from you is the freedom to say let second = first and keep using first. When you want that, you say .clone(), and the cost is right there in the source where a reviewer can see it.

The signature tells you what the function does with your value, which is information a Swift signature simply does not carry. fn consume(items: Vec<i32>) takes the vector — the caller loses it. &Vec<i32> borrows it to read. &mut Vec<i32> borrows it to write, and is exactly Swift's inout (right down to the & at the call site). The rule of thumb when writing Rust: borrow by default, and take ownership only when you genuinely need to keep or destroy the value.

One writer or many readers, checked at compile time. That single rule buys you the elimination of an entire class of bugs — iterator invalidation, use-after-free, and data races are all the same mistake (mutation through one alias while another alias is live), and none of them can be written. Swift catches the memory-safety half of this with ARC and exclusivity checks at run time, and simply permits the rest. The cost is the one everybody complains about: the borrow checker rejects programs that are actually fine, and learning to restructure code so it agrees is the real Rust learning curve. It gets shorter than you expect.

A lifetime is not a thing that exists at run time; it is a constraint the compiler checks and then erases. <'a> on the signature above says "the reference I return is valid for as long as the shorter of my two inputs", which is exactly the fact ARC establishes dynamically by keeping the object alive. Rust establishes it statically and frees the memory at a point it can prove is safe — which is why there is no reference counting, no atomic increment, and no deallocation happening at an unpredictable moment. The good news for a Swift developer: lifetime elision means you almost never write one. The bad news: when you do have to, the error message that sent you there is the hardest one in the language.

The default is inverted. Every Swift class pays for reference counting — atomic increments and decrements, on every assignment, forever — because the compiler cannot know whether you will share it. Rust's default is a single owner with zero runtime cost, and shared ownership is a type you opt into: Rc for one thread (a plain counter) or Arc for several (an atomic one, the exact cost Swift always pays). deinit becomes the Drop trait, and it runs at a point the compiler determined statically rather than when a counter happens to hit zero.

Rust has the same escape hatch (Weak, obtained with Rc::downgrade, and turned back into a real reference with .upgrade(), which returns an Option because the target may be gone). It also has the same hole: an Rc cycle leaks, and the compiler will not catch it. What is different is how much noise Rust makes about shared mutable state on the way there — Rc<RefCell<T>> is deliberately ugly, because RefCell moves the borrow check from compile time to run time (it panics if you take two mutable borrows at once). That ugliness is a signal, and the usual Rust response is to redesign the data structure — an arena with indices, or a tree that owns its children one way — rather than to reach for Rc at all. A Swift graph of mutually referencing classes is often the wrong shape for Rust entirely.

Almost a straight port: Optional<T> is Option<T>, if let is if let, and guard let … else is let … else — including the rule that the else branch must diverge. The difference is that Swift's optionals come with dedicated syntax (?., ??, !, ?!), while Rust's Option is a plain enum from the standard library, so the syntax becomes methods: map for optional chaining, unwrap_or for ??, unwrap() for the force unwrap (and expect("why"), which is the same thing with a message — always prefer it). Being an ordinary type has a real payoff: Option composes with generic code, and you can write your own types that behave exactly like it.

The mapping is direct — throws becomes -> Result<T, E>, try becomes the postfix ?, try? becomes .ok(), and do/catch becomes a match — and the consequences of a failure being an ordinary value run deeper than the syntax. A Result can be stored in a struct, collected into a Vec, mapped over, or returned from a closure, none of which a thrown Swift error can do. It also means the error type is part of the signature (Swift only got typed throws recently, and it is rarely used), so a caller knows precisely what can go wrong. The idiomatic escape from writing that type by hand is a library — thiserror to define errors, anyhow when you just want one type that swallows everything.

The distinction is the same one Swift draws and states more plainly: Result is for failure you expect (bad input, missing file), panic! is for a bug (a broken invariant, an index that cannot be out of range). panic! is fatalError, assert! is precondition, and unreachable!() exists too. catch_unwind can technically catch a panic, but using it as an exception handler is a well-known anti-pattern — a panicked thread may have left data in a half-updated state, which is precisely what the type system was preventing everywhere else. Note the .get(10) reflex in the right column: for almost every panicking operation, Rust also offers a version that returns an Option or a Result, and idiomatic code reaches for that one.

This is a rename, not a translation: switch is match, case .circle(let radius) is Shape::Circle { radius }, and both compilers reject a missing case. Two small differences to absorb. Rust variants must be qualified with the enum name (Shape::Circle, not .circle) unless you use Shape::* — the leading-dot shorthand does not exist. And Option and Result are ordinary enums declared in the standard library, not language features, which is why everything you learn here applies to them directly.

The pattern language is a superset of what you know. Swift's where clause is Rust's if guard, and Rust adds range patterns (0..=100, matched inline rather than through contains), alternation with |, and the @ binding, which captures a value while testing it (first @ 1..=9). The one thing to get used to is the * in *value > 100: because message is a reference, the bindings are references too, and comparing one to a number means dereferencing it. That is the borrow checker showing up somewhere you did not expect it, and it is the most common paper cut in a Rust match.

Two ideas collapse into one. Every Rust struct is a value; whether it is shared depends on whether you pass it by value, by reference, or inside an Rc. So mutating func becomes &mut self, an ordinary method becomes &self, and a Swift class becomes a struct plus the sharing strategy written out at the use site. Two things to note in the right column: methods live in an impl block outside the struct (so you can add several, and implement traits, without touching the data definition), and the behaviors Swift gives you for free — printing, copying, equality — are opted into with #[derive(Debug, Clone, Copy, PartialEq)]. If you forget to derive Debug, you cannot even print the thing, which is the most common five-second compile error in Rust.

The correspondence is unusually tight: a protocol is a trait, a protocol extension is a default method, <T: Describable> is <T: Describable>, and any Describable is dyn Describable. Two differences with real consequences. Rust's impl block is separate from the type, so you can implement your trait for someone else's type (impl Describable for i32) — the coherence rules only require that either the trait or the type be yours. And dyn Trait must live behind a pointer (Box<dyn Trait>, &dyn Trait), because a trait object has no size known at compile time; Swift hides that boxing inside any, and Rust makes you type it, which is the same philosophy as clone() — the allocation is visible in the source.

Rust has no inheritance at all — no base class, no super, no override. Polymorphism is traits, and code reuse is composition: the shared behavior moves into a trait's default methods, and the shared data becomes a struct you embed as a field (and then re-expose, which is the boilerplate this design costs you). Swift already pushes you this way — protocol-oriented programming is the house style, and structs are the default — so the change is less violent than it sounds. It is worth being honest about the cost: a deep class hierarchy does not port, and trying to recreate one with traits and Box<dyn> fights the language the whole way.

A Vec<T> is an Array and a HashMap<K, V> is a Dictionary, with two things worth flagging. Indexing a Vec out of bounds panics (Swift traps too, so this is familiar), while .get() returns an Option — reach for that one. And HashMap's entry API (*map.entry(key).or_insert(0) += 1) does a lookup-and-insert in a single hash, which Swift needs two operations for; it looks strange and it is the idiom to learn. Note also that Rust's HashMap is unordered and randomly seeded, so anything you print must be sorted first — as above.

The vocabulary is the same, but the defaults are swapped: Swift's map/filter are eager and each allocates an array (with .lazy as the opt-in), while Rust's iterator adapters are lazy and do nothing at all until a consumer — collect(), sum(), find(), a for loop — drives them. That means one pass over the data with no intermediate allocation, and it means forgetting .collect() is the classic beginner error (the compiler complains that a Map<Filter<…>> is not a Vec, which is bewildering until it is obvious). The other daily adjustment: there is no $0 — every closure names its parameter.

The String / &str split is ownership applied to text: String is a heap-allocated buffer you own (Swift's String), while &str is a borrowed view into one (a slice — closer to Swift's Substring). The rule that resolves ninety percent of the confusion: take &str as a parameter, return String when you produce something new. Two traps for a Swift developer. len() returns bytes, not characters — .chars().count() is what you meant. And a Rust char is a Unicode scalar, not a grapheme cluster, so an emoji flag counts as two; Swift's Character is grapheme-correct out of the box, and matching it in Rust needs an external crate. This is the one section where Swift is unambiguously ahead.

The structural difference is that in Rust the lock owns the data. There is no way to read the counter without going through lock(), because the integer lives inside the Mutex — so "forgot to take the lock" is not a bug you can write, and the guard releases at end of scope, so "forgot to unlock" is not either. Arc is the thread-safe Rc, and move hands the closure ownership of what it captures. Behind it all, the Send (safe to transfer between threads) and Sync (safe to share by reference) marker traits are what let the compiler reject a data race as a type error — the guarantee Swift 6 is now reaching for with Sendable, arrived at from a very different direction.

Rust has async/await as syntax, and then stops: an async fn returns a Future, a Future does nothing until it is polled, and nothing in the standard library polls it. You choose an executor — tokio, in practice — and that decision colors your whole dependency tree. Swift, by contrast, ships the runtime, the cooperative thread pool, and structured concurrency in the language. Two more gaps: there are no actors in Rust (an actor is Arc<Mutex<T>>, or a task owning the state and receiving messages over a channel), and there is no task tree — Swift's withTaskGroup cancels its children automatically, while a Rust JoinHandle is detached unless you go out of your way. What Rust has instead is Send/Sync, which means the compiler proves the whole thing is race-free rather than asking you to adopt an actor.