Elixir.CodeCompared.To/Rust

The exclamation mark matters: println! is a macro, not a function, and the trailing ! is how Rust spells that everywhere. There is no script mode and no .exs equivalent — cargo run merely hides a compile step that always happens. What you get for it is a single static binary with no runtime to install, where a release still ships the whole BEAM.

This is the trade the whole page turns on. You give up the freedom to write anything and have it mean something at runtime; you get back a compiler that rejects a category of crash before the code ships. Note the second half of the bargain: Rust has no implicit conversion anywhere — not even i32 to i64 — so parsing returns something that can fail and you are made to deal with it.

Shadowing is the faithful translation of Elixir rebinding, and it can even change the type — let input = "7"; let input: i32 = input.parse().unwrap(); is idiomatic. mut is the genuinely new thing: the value itself changes, which on the BEAM is not expressible at all.

Nothing stops you calling Doubling.double("x") and finding out in production. In Rust the annotation is mandatory on function boundaries and optional almost everywhere else, because inference fills in the rest — you will write far fewer type annotations than you expect, just never on a function signature.

This is the idea everything else is built on. Exactly one variable owns a value; when that owner goes out of scope the memory is freed, immediately and deterministically. There is no garbage collector to decide later — which is why a Rust NIF has no GC pause to add to your latency budget, and why the compiler has to be this strict to stay safe.

A shared reference &T is read-only, so several may exist at once. Reading a signature is how you learn a function's intentions: &[i64] promises to look and give it back, &mut Vec<i64> announces it will change the caller's value, and a bare Vec<i64> means it is taking the thing for keeps.

A .clone() is a genuine deep copy and it is deliberately noisy in the source, because it is the line where you spent memory and time. Reaching for it to quiet the borrow checker is the classic beginner move; it works, it is not a crime, and you will slowly replace those calls with borrows as the model clicks.

A lifetime is not a runtime value and it does not change what the code does — it is a proof obligation, erased before anything runs. A BEAM term simply lives until the per-process garbage collector decides otherwise, so nothing on that side corresponds. The good news is that elision rules cover the overwhelming majority of functions and you will write these annotations rarely.

The deep difference is that Elixir's = is a match operator that happens to bind, so a failed match raises MatchError at runtime. Rust's let only accepts an irrefutable pattern — one that cannot fail — and anything that might fail must be written as if let or match, checked at compile time.

Note the semicolon after the closing brace: match is an expression being assigned, so the statement has to be terminated. Rust took this construct from the ML family for the same reasons Elixir did, and it is the single largest piece of your existing intuition that transfers unchanged.

Exhaustiveness is what makes an enum worth declaring. Add a fourth light six months from now and the compiler walks you to every match that needs updating, which is the refactoring story Elixir cannot tell — there, a new atom flows silently through the system until some clause somewhere fails to match it.

Rust does warn when a pattern shadows a constant, but only for constants — shadowing an ordinary let binding is accepted in silence, and the arm then matches every input. If a match arm is firing when it should not, this is the first thing to check.

An Elixir struct is a map with a __struct__ key, so it carries its defaults and will accept a missing field. A Rust struct is a compile-time layout with no tag and no defaults, and leaving out age is an error. The #[derive(Debug)] line is what makes {person:?} printable at all — see the macros section.

The tagged tuple is a convention held together by discipline: nothing stops {:circle, "two"}, and a typo like {:circel, 2} travels quietly until something fails to match it. The enum closes the set, so a misspelled variant is a build error and a new variant forces every match to be revisited.

There is no nil in Rust at all — no null pointer, no universal absent value. || becomes unwrap_or, and where you would write a case on nil you write a match the compiler checks. This closes Hoare's "billion dollar mistake" at the type level, and it is one of the two or three things that will make you miss Rust when you go back.

Because it is a real type rather than a convention, the compiler knows an unhandled Result when it sees one and warns you about it. The Elixir habit of a bare {:ok, _} match that crashes on {:error, _} has no quiet equivalent — you either handle the error branch or say explicitly that you are not going to.

The ? operator returns early on Err, converting the error through the From trait on its way out. There is no else block, and that is the real difference: with funnels every failed clause into one place where you have lost track of which clause failed, while ? propagates each error as itself and the signature names the type that can come out.

Do not read panic! as "let it crash." The BEAM phrase assumes a supervisor underneath that will notice and restart; nothing of the kind exists here. A panic unwinds the current thread, and if that is the main thread the process exits with a non-zero status. Rust's division of labor is strict: Result for what you expect to go wrong, panic! for what should have been impossible.

Note that the Rust error is a value returned from a function, not something thrown past every frame between here and a handler: it appears in the signature, and a caller that ignores it gets a warning.

The type annotation on result is not decoration — sum() is generic over what it produces, so the compiler needs to be told. This is the most common place a newcomer meets "type annotations needed", and the fix is almost always to annotate the binding or write .sum::<i32>().

The chain does no work until collect() drives it, so only five elements are ever produced. And because the adapters are ordinary generic structs that the optimizer can see through, the whole pipeline usually compiles to the same machine code as the hand-written loop — laziness here costs nothing, where Stream trades allocation for a small per-element overhead.

Indexing with inventory["apples"] panics on a missing key, exactly as Elixir's Access would return nil and then fail a step later. The safe form is inventory.get("apples"), which gives you an Option — and reaching for it by reflex is a good habit to build early.

Note 1..=3: Rust's .. excludes the upper bound and ..= includes it, where Elixir's .. is always inclusive. This is a quiet off-by-one waiting to happen, and it is worth over-checking for the first few weeks.

Both print 11, because both count bytes. The rule of thumb that will serve you well: take &str in function parameters, return String when you built something new. Reaching for String everywhere works and allocates more than it needs to.

The braces are a mini formatting language rather than an escape into the host language: {value:?} asks for the Debug representation, {value:.2} rounds a float, {value:>8} right-aligns. Elixir's #{} can hold any expression; Rust's inline capture can hold only a name.

Elixir's String functions work on graphemes — what a reader would call a character. Rust's chars() yields Unicode scalar values, one level below that, so a flag emoji or a combining accent counts as several; true grapheme clusters need the unicode-segmentation crate. And text[0] does not compile, because a byte offset into UTF-8 is not necessarily a character boundary.

Every element of parts is a borrowed slice pointing into line — no copying happens, and the borrow checker guarantees line outlives them. That is the ownership model paying you back: the obvious code is also the allocation-free code.

This is one of the few places where Rust is plainly more verbose than Elixir for no gain you can feel day to day. The idiomatic replacements are a differently named function, an Option parameter, or — once the argument list grows — a builder struct. Trait methods do give you a form of dispatch, but on the receiver's type, never on a value.

What Rust adds is how the capture happens — by shared reference, by mutable reference, or by value with move — and the compiler picks the least restrictive option that compiles. That choice is invisible until a closure outlives what it captured, at which point the error message tells you to add move.

Writing that as one chain fails with "temporary value dropped while borrowed" — to_uppercase() produces a String that would die at the end of the statement while words still points into it. This is the borrow checker turning up in a spot where an Elixir pipeline has nothing to say, and binding the intermediate is the whole fix.

The move is mandatory here: factor lives on build's stack frame, which is gone by the time the closure runs, so it must be captured by value. Elixir has no such requirement because a closure copies what it captures into a heap-allocated term the garbage collector keeps alive.

Two real differences. Rust resolves the call at compile time by default, where a protocol is a runtime lookup on the term's type. And coherence — the orphan rule — requires that either the trait or the type be local to your crate, so you cannot implement someone else's trait for someone else's type; Elixir lets any application defimpl anything for anything. (The Elixir cell is display-only here only because AtomVM compiles a protocol with two implementations too slowly to run in the browser; the dispatch itself is fine.)

The compiler generates a separate specialized copy of largest for each concrete type you call it with — monomorphization — so the abstraction costs nothing at runtime. The bill arrives as compile time and binary size instead, which is the trade Rust makes almost everywhere.

dyn Shape is the opt-in to runtime dispatch through a vtable — precisely what every Elixir call already does, for free, all the time. Box is required because a trait object has no size known at compile time. Notice the price of getting the heterogeneous list back: one allocation per element and one pointer indirection per call.

Elixir's ++ builds a new list and leaves the old one untouched, which is why appending in a loop is a well-known performance trap. push amortizes to constant time because it really does write into the existing buffer — the same operation the BEAM cannot offer at any price.

You already have this guarantee, obtained differently: the BEAM makes everything immutable and deep-copies across process boundaries, so no two writers can ever see the same memory. Rust proves the same property at compile time and then lets you mutate — which is the entire bargain, and the only genuinely hard part of learning the language.

Both compile to the same thing, so the choice is about reading. The Elixir instinct to reach for reduce transfers fine, but resist writing a fold where the body is genuinely imperative — Rust programmers read the loop faster, and there is no purity argument to be made when the whole language permits mutation.

The cost model is the thing to internalize. A BEAM process starts at a few hundred words and you can hold millions of them; thread::spawn creates a real operating-system thread with a stack measured in megabytes, so you will run tens or hundreds and reach for a thread pool beyond that. Cheap concurrency in Rust lives in the async section instead.

A channel is typed, so a worker cannot send a message the consumer was not built to handle — a real gain. The drop(sender) is the part that catches people out: the receiver keeps waiting while any sender is alive, and the original one is still in scope.

This is the BEAM feature with the least satisfying replacement. Selective receive lets a process defer work it is not ready for and pick it up later, which is how GenServer handles out-of-order replies and how a state machine ignores events belonging to another state. In Rust you model priority as separate channels and choose between them with tokio::select!, and once a message is off a channel it is gone.

Sit with this one — it is the largest conceptual reversal on the page. Arc is the atomic reference count that lets several threads own the same value; Mutex is the lock. What Rust adds over every other language with locks is that the data lives inside the mutex, so there is no way to read it without locking: forgetting is a compile error rather than a race you find in production.

These two traits are applied automatically by the compiler, so you almost never write them — you only meet them in an error message explaining why something cannot cross a thread boundary. That message is the compiler catching, at build time, the exact class of bug the BEAM avoids by copying: it is the same guarantee, bought with analysis instead of memory bandwidth.

A panicking thread does not take the process down, and join() hands back an Err — so far so similar. There the resemblance stops. There is no supervisor, no restart strategy, no :one_for_all, no link graph propagating the failure to everything that depended on the worker. You get one result about one thread, and rebuilding it is your problem. This is worth remembering before describing a Rust service as fault-tolerant.

Three differences matter. Scheduling is cooperative, so a task that blocks without awaiting starves its whole worker thread, where a BEAM process is preempted after a fixed reduction budget no matter what it does. Tasks share memory with each other, so everything in the previous section still applies. And there is no runtime in the language: you choose and start one, which is what #[tokio::main] does.

This is what people mean by "function coloring": async code can only be awaited from async code, so the choice propagates up through every caller and a library often has to publish both forms. It is the tax Rust pays for having no runtime of its own, and the single largest structural difference from a language where the scheduler is simply always there.

The difference is what you write the macro in. An Elixir macro is an ordinary function that receives AST and returns AST, so the whole language is available while building it. macro_rules! is a separate pattern-matching mini-language over token trees, deliberately limited. Writing Rust to generate Rust means a procedural macro, which has to live in its own crate — a much heavier step than defmacro.

Forgetting Debug and then trying to print the struct is a rite of passage, and the error message names the fix. The upside of opting in: comparing two values of a type that has no sensible notion of equality is a compile error, where Elixir's == compares any two terms whatsoever and returns a confident, meaningless answer.

Rustler is the reason this pairing exists in practice rather than in theory: it handles term conversion, panic catching at the boundary, and the build integration through mix compile.rustler. Reach for it when profiling has actually shown you a hot loop — the boundary is not free, and a NIF wrapped around trivial work is routinely slower than the Elixir it replaced.

This is the most important row on the page. The supervision tree that has caught every failure of your career cannot reach inside a NIF, so the isolation you have been relying on stops exactly where this code begins. Rustler does catch unwinding panics and turn them into an Elixir error, which helps enormously — but panic = "abort", a stack overflow, or unsafe code will still take the node down. Write NIFs that return Result, and index with get.

The one-millisecond guideline comes from the Erlang documentation and is meant seriously. Exceeding it does not fail loudly — it shows up as unexplained latency in processes that have nothing to do with your NIF, which is a genuinely difficult thing to diagnose after the fact. The fixes are the dirty scheduler above, or chunking the work and yielding between pieces.

That conversion is a real cost and it is easy to overlook when reasoning about whether a NIF is worth it. Every term is copied across the boundary in both directions, so native code doing modest work on a large binary can lose to the pure Elixir version outright. When the data is big and the work is small, pass a reference-counted binary and measure before believing anything.

Coming from Mix you will feel at home immediately, down to cargo fmt settling formatting arguments the way mix format did. The one genuine addition is cargo clippy, a lint suite with no real Elixir counterpart — Credo is the nearest thing, and Clippy is both more aggressive and more often right.

Version syntax differs in a way worth reading carefully: Elixir's ~> 1.4 allows 1.5 but not 2.0, while Cargo's bare "1.0" is already a caret requirement meaning the same thing. Cargo's feature flags have no Hex equivalent — they conditionally compile parts of a dependency, which is how one crate serves both an embedded target and a server.