Lua.CodeCompared.To/Rust

Because it is a macro, the format string is checked at compile time: too few arguments for the placeholders is a build error rather than something you discover in production. Lua's string.format checks nothing until it runs.

So Lua's print is closest to println! and io.write is closest to print!. The one to remember for debugging is {:?}, the Debug format, which prints a structure the way you would type it — the counterpart of writing an inspect function by hand in Lua.

The third form has no Lua counterpart. A /// comment is Markdown that cargo doc renders into HTML — and any code block inside it is compiled and run by cargo test, so documentation examples cannot rot without the build noticing.

The semicolon is what distinguishes the two: "pass" is the block's value, and "pass"; would be a statement that discards it, leaving the function returning nothing. return does exist and is used for early exits. The &'static str return type says "a borrowed string that lives for the whole program", which is what a literal is.

This is not a rule about function calls — it is a rule about assignment, and calls are one case of it. Each value has exactly one owner; when ownership moves, the old name becomes unusable, which is how Rust knows there is exactly one place responsible for freeing it. The Lua column's answer, that both names see the change, is the thing the next two rows show how to ask for.

So the everyday Rust equivalent of a Lua function taking a table is one taking &Vec<T> — or better, &[T], a slice, which also accepts arrays. The compiler guarantees the borrow cannot outlive the value, so unlike a C pointer there is nothing to check at run time and nothing to get wrong.

Both columns print 3; the difference is that Rust made you sequence the writes. The borrow ends at its last use rather than at the end of the block, which is why list.push("c") is accepted on the following line — that refinement is called non-lexical lifetimes and it is why modern Rust complains far less than its reputation suggests.

Rust names the operation and puts it in the standard library, and the fact that you must write .clone() is deliberate: an allocation is never implied by an assignment. The convention worth knowing is that a visible .clone() in a hot loop is a code-review conversation, in a way that Lua's hand-rolled copy loop never is.

A type that implements Copy is duplicated on assignment instead of moved — every integer, float, bool, char, and any tuple or struct made only of those. Lua draws the same line in the same place: numbers, booleans and strings are values, while tables and functions are references.

Returning the value itself is fine — ownership moves to the caller. Returning a reference to a local is rejected, because the local is gone by then; that is the whole content of the phrase "the borrow checker". The Lua column is doing the same thing in effect: the closure keeps inner reachable, so the collector leaves it alone.

Rc is a reference count, so several owners share one value and it is freed when the last is dropped; RefCell moves the one-writer rule from compile time to run time, panicking if two borrows overlap. Together they are a Lua table: shared, mutable, reference-counted. Note what you gave up — the aliasing bug the compiler was catching for you is now a run-time panic — and note what Lua gives up in exchange: its collector, running everywhere, all the time. For sharing across threads the pair is Arc<Mutex<T>>.

Inference is local but thorough: it works backwards from how a variable is later used, so let numbers = Vec::new(); followed by numbers.push(1) works out that this is a Vec<i32>. What it will not do is cross a function boundary — every signature must be spelled out, which is deliberate, so a change inside one function cannot silently retype another.

The practical effect is that mut becomes a signal you read: a binding without it is a promise, both to the compiler and to the next person. It also composes with borrowing — &mut is only obtainable from a mut binding — so the two rules reinforce each other rather than being separate things to remember.

Both print 43. The reason it matters more in Rust is that the second binding may have a different type, which is how the parse-then-use pattern avoids inventing a name like value_as_number. This is not mutation: the first value still exists and is simply no longer reachable by that name.

There is no implicit global scope: a name must be declared, and a misspelling is a compile error rather than a fresh global holding nil. Mutable global state is possible but deliberately awkward — a static mut requires unsafe, and the ordinary answer is to pass the value in or use a OnceLock.

Rust has no conversion from any type to bool, so there is no falsy set and no accidental truthiness. The cost is that each check has to name what it means: is_empty(), is_none(), == 0. The gain is that the most common Lua-to-anything porting bug — a 0 that was true in one language and false in the next — cannot be written.

Lua's or replaces anything falsy, so enabled = enabled or true can never be false. unwrap_or replaces absence and nothing else. The family is worth learning together: unwrap_or_else takes a closure when the default is expensive, and unwrap_or_default uses the type's zero value.

The Lua idiom silently returns c whenever b is false or nil, which is why enabled and false or true yields true. Rust's if cannot fall through, and the compiler additionally requires both arms to have the same type — so the version that would have surprised you does not build.

Because Option<&str> and &str are different types, a function that cannot accept absence simply does not have to check for it — the compiler already refused every caller who might pass one. In Lua, any parameter can be nil, which is why so many Lua functions open with a guard.

get hands back an Option, so the absence is visible in the type and cannot be mistaken for a value further down. The indexing form ages["bob"] also exists and panics — that is the deliberate split throughout Rust: an Option-returning method when absence is expected, and a panicking shortcut when it is a bug.

Inside the block, age is a number and needs no further checking, which is the point: the check and the use cannot drift apart. Where the else branch exits, let Some(age) = … else { return; }; is the flatter spelling and reads much like an early-return guard in Lua.

The family is large and worth browsing once: map, and_then for a function that itself returns an Option, filter, ok_or to turn absence into an error, and ? to return early from a function that returns Option. Nothing in Lua corresponds — the and/or chain is as far as it goes.

&str is a borrowed slice of text somebody else owns — a literal, or part of a String. String owns a heap buffer and can grow. The rule of thumb: take &str in function parameters so callers can pass either, and return String when you built something new. Unlike Lua's strings, a String is mutable, which the Gotchas section puts to use.

format! is the workhorse: same syntax as println! but returning a String. + does concatenate strings, awkwardly — it takes an owned String on the left and a &str on the right, so "a" + "b" does not compile. Reach for format! and stop thinking about it. Note also 1..=3, an inclusive range, which is Lua's for index = 1, 3 exactly.

Neither # nor .len() counts characters, so any string with an accent in it reports more than you can see. Both languages then give you a way to ask properly — Lua 5.3's utf8 library and Rust's chars() iterator, both of which walk the encoding. The deeper difference is that Rust guarantees a String holds valid UTF-8, while a Lua string is an arbitrary byte sequence that may not be text at all — which is why utf8.len can return nil and Rust has a separate Vec<u8> for bytes that are not text.

Rust rejects word[0] because there is no honest answer: a byte is not a character and a character is not always one byte. So you choose — &word[0..1] for a text slice, as_bytes() for raw bytes, chars().nth(0) for a character. Both columns print c then 99; Lua's byte and Rust's as_bytes are the same operation. A slice that splits a multi-byte character panics.

0..4 is a range that stops before 4, which is why the two spellings pick out the same four characters from different-looking numbers. Rust has no counterpart to Lua's -8, so the arithmetic is yours — and it must be right, since an out-of-range slice panics where Lua's sub quietly clamps.

For the common cases the methods are clearer than a pattern: split, splitn, strip_prefix, trim, find, replace, starts_with. When you genuinely need a regular expression, the regex crate is the universal answer and is faster than most languages' built-in engine — it is simply not in std, which is a deliberate choice about what the standard library should carry. The extra parentheses in the Lua column discard gsub's second return value, the replacement count.

Being homogeneous is the bigger change, not being split. A Lua table happily holds a number, a string and a function; a Vec<i32> holds integers. When you genuinely need a mixed collection the answer is an enum listing the possibilities, which the Matching section covers — and which turns "what is in here?" from a run-time question into a compile-time one.

Prefer colors.last().unwrap() to the length arithmetic: it returns an Option, so an empty collection gives None instead of panicking on 0 - 1 — and on an unsigned usize that subtraction is itself an overflow. Note also that an out-of-range index panics in Rust, where Lua hands back nil and lets the mistake travel.

A Vec<T> is a growable heap array — the direct counterpart of a Lua table used as a list. Rust also has fixed-size arrays ([i32; 3], on the stack, length in the type) and slices (&[i32], a borrowed window onto either). Lua has one structure where Rust has three, and the distinction is about where the memory lives.

Lua's (counts[word] or 0) + 1 reads the key and then writes it, hashing twice. entry looks the slot up once and hands back a handle you can fill in — so or_insert supplies the default and the * dereferences the resulting &mut i32 to add to it. Same idea, one lookup, and no way to typo the key on the second line.

Lua's pairs order is undefined, which in practice means stable for a given build and then different on somebody else's machine. Rust randomizes the hash seed per process, so an accidental dependence on order fails on the second run rather than in production. Where you want order, use BTreeMap, which keeps keys sorted and iterates in that order — the Iterators section uses it.

A tuple is the lightweight option — no name, fields reached by position, good for returning two things. A struct costs a declaration and buys names, methods and a type the compiler can check. The middle ground is a tuple struct (struct Meters(f64);), which wraps one value in a distinct type so meters and feet cannot be mixed up — a kind of safety Lua has no way to express.

sort_by_key covers most cases; sort_by takes a full comparator returning an Ordering, and bare sort works when the elements are already comparable. Two behaviors differ from Lua: Rust's sort is stable, so equal elements keep their relative order, and it cannot be given an inconsistent comparator by accident — where a bad Lua comparator raises "invalid order function" at run time.

The chain compiles to roughly the same machine code as the hand-written loop, which is what "zero-cost abstraction" means in practice. Two details for a newcomer: iter() yields references, hence the *number to compare against a number, and collect() is what decides the result type — annotating Vec<String> is how it knows what to build.

The odd-looking fold is worth the detour: there is a max() on iterators, but it requires Ord, and floats are not totally ordered because NaN compares false against everything. So Rust makes you say what you want with NaN present rather than guessing — a small example of a large habit. Both columns format their floats explicitly, since Lua prints a float as 12.0 and Rust prints an f64 as 12.

The iterator borrows numbers, so the compiler refuses any modification while it is alive — the laziness cannot surprise you, because the aliasing that would make it surprising is rejected. This is worth noticing as a pattern: the borrow checker is not only about memory safety; it rules out logic bugs that GC'd languages leave to your discipline. The Lua column, being eager, was never at risk in the first place.

Two things do the work. or_default() creates the empty Vec when the key is new, replacing Lua's byLetter[letter] or {}; and BTreeMap keeps its keys sorted, so the whole collect-and-sort-the-keys dance at the bottom of the Lua column is unnecessary. The itertools crate does have chunk_by, and reaching for a crate for this is normal Rust rather than a failure.

iter() borrows each element, iter_mut() borrows each mutably so the loop can change them in place, and into_iter() — which a bare for word in words calls — takes ownership and leaves the collection consumed. When a loop unexpectedly refuses to compile, the usual fix is &collection or .iter(). That is why the Rust column here prints its items twice: the two loops are two different operations.

An fn must annotate every parameter and its return type — inference stops at the boundary on purpose, so changing one function's body can never silently retype another. A closure written with |…| may leave them out, because it is used nearby and the compiler can see how. Note the naming convention too: Rust is snake_case throughout, which happens to be Lua's common style as well.

The difference shows up when a call sits inside a larger expression. Lua adjusts a multi-value call to a single value in most positions, so print(divide(17, 5), "x") prints only the quotient — a real source of confusion. A tuple is one value everywhere, so nothing silently disappears. Also note Lua's //: since 5.3, / always produces a float, so integer division needs its own operator, where Rust's / on two integers is already integer division.

This is why println! is a macro: macros run at compile time and can take any number of arguments, which is how the standard library offers a printf-shaped interface without the language having varargs. Writing your own macro_rules! for this is possible and rarely worth it — a slice parameter is idiomatic and reads fine.

..Default::default() is the struct-update syntax — take these fields, fill the rest from the default — and it is the closest thing Rust has to named optional arguments. Note the gain over the Lua column: the defaults are stated once, in one place, and every field is named at the call site rather than counted. The heavier version of this pattern is a builder, which is what libraries expose when there are many options.

move takes ownership of count, which is required because the closure outlives the function. FnMut says the closure mutates what it captured, which is why counter itself must be let mut — calling it changes it. The three traits are the whole taxonomy: Fn only reads, FnMut mutates, FnOnce consumes and can be called once. Lua's closures are all quietly FnMut, and the upvalue is reference-counted for you.

The struct is the data and the impl is the behavior, and separating them is what lets you write several impl blocks for one type. new is a convention rather than a keyword — there is no special constructor, just an associated function returning Self. Note &mut self on deposit: the method says it modifies the account, which is why account had to be declared mut.

Rust's self comes in three forms, and each is a claim: &self borrows to read, &mut self borrows to modify, and bare self takes ownership so the value is consumed by the call. That last one has no Lua counterpart at all and is worth recognizing — a method named into_something conventionally takes self, and the original is gone afterwards. What Rust does not have is Lua's dot-versus-colon hazard: there is one call syntax, so forgetting the receiver is impossible.

A default trait method is the piece that recovers what you actually wanted from inheritance: shared behavior, overridable per type. What it does not give you is inherited fields, which is why both structs declare name and both implement the accessor. When that duplication grows, the answer is composition — hold the shared struct as a field — and Rust's position is that this was always the better design and the language simply declines to offer the other one.

&impl Shape is a generic parameter, so the compiler generates a specialized describe for each type and the calls are direct — no lookup at run time, unlike Lua's metatable walk. When you need a collection of mixed types instead, &dyn Shape uses a vtable and behaves more like what Lua does. Rust's traits are nominal: a type with matching methods that does not say impl Shape will not be accepted.

Display is the human-facing form, written by hand because only you know how the type should read. Debug is the programmer-facing form and is derived: one line generates a representation showing the field names, which is what {:?} prints, and {:#?} pretty-prints it over several lines. Getting a structure dump for free is the thing Lua programmers most often write an inspect helper for.

Two differences. Operator overloading in Rust is just trait implementation, so it uses the same mechanism as everything else and gets the same coherence guarantees — where Lua picks whichever operand happens to carry the metamethod, which can be asymmetric and surprising. And note fn add(self, …): addition consumes both vectors here, so a type meant for arithmetic normally derives Copy or implements Add for references too.

#[derive(…)] generates trait implementations from the shape of the struct: PartialEq compares field by field, Clone copies field by field, Debug prints the fields, and Hash, Default, PartialOrd and Copy are all available the same way. This is the habit to pick up — a data-carrying struct in real Rust almost always opens with a derive list, and hand-writing these is reserved for the cases where the default is wrong.

A Rust enum is a tagged union: exactly one variant at a time, each carrying its own data of its own type. That is what makes the match below it safe — inside the Text arm, text is a String, and no branch can misread the payload. This is the single most-loved feature of the language, and it is also what Option and Result are built from.

The word doing the most work is exhaustive: match must cover every possibility or the code does not compile, so _ is the catch-all. Over an enum that is transformative — add a variant, and every match that has not been updated becomes a build error rather than a silent fall-through to the else. number if number < 0 is a match guard, and patterns can also be ranges (2..=9) or alternatives (1 | 2).

The arms are tried in order, so the specific ones must come first — as with the Lua ladder, and as easy to get wrong. What you gain is that the shape being tested is legible at a glance: 21.. is a half-open range pattern and .. means "and the other fields, whatever they are". Patterns nest, so Order { customer: Customer { country: "GB", .. }, .. } is a valid arm.

A Result is an enum with two variants, so the caller cannot reach the number without acknowledging the other case — and the compiler warns about a Result that is discarded entirely. Compare the failure modes: a Lua caller who writes local number = parse(text) gets nil and carries on, which is exactly the bug this type exists to prevent.

pop returns Option<T>, and while let keeps looping as long as the pattern matches — so the emptiness check and the removal are the same operation and cannot disagree. Both print c, b, a. This shape recurs constantly in Rust: any function returning an Option can drive a while let.

? is the whole ergonomic story: on Ok it unwraps the value and carries on, and on Err it returns that error from the enclosing function immediately. So total reads almost like the Lua version while still being honest about failing. The trade-off is visible in the signature: every function on the failure path must return a Result, which is more typing and also a map of exactly where things can go wrong.

Rust has no exceptions and no throws clause to ignore — the failure is part of the value the function hands back, so the type system carries the information that Lua leaves to a docstring. The practical effect on a codebase is that you can see the failure surface by reading signatures, and adding a new failure mode to a function is a change its callers are forced to notice.

A Result is for failures the caller should handle: a missing file, bad input, a refused connection. A panic! is for a broken invariant — an index out of range, a failed assertion, a None you promised would be Some — and it is not meant to be caught. The library convention follows the split, which is why first() returns an Option and [0] panics: same question, two answers, depending on whether absence is expected.

catch_unwind exists for two narrow jobs: stopping a panic at an FFI boundary, where unwinding into C is undefined behavior, and supervising a worker thread. It is deliberately awkward — the closure must be unwind-safe, the default handler prints to stderr unless you replace it, and a build configured with panic = "abort" makes it useless. Everyday recoverable failure is Result, and reaching for this instead is the clearest sign of a Lua reflex.

unwrap() turns None or Err into an immediate panic; expect("…") does the same with a message, and is preferred precisely because the message states the assumption that turned out to be false. Neither is shameful in a place where the invariant really does hold — but each one is a claim, and the reviewable question is whether the claim is true.

Both are lazy: nothing runs until the loop asks. What Rust does not have is a way to write that suspension yourself on stable — there is no yield keyword available, so a generator is not an option and you either compose existing iterators, as here, or implement the Iterator trait, as the next row does. Generators have been in the works for years and remain nightly-only.

What a coroutine gives you for free is exactly this: the compiler working out what state to keep across a suspension. Writing it by hand is mechanical rather than hard, and it does buy something back — Fibonacci is an ordinary value you can store, clone or pass around, and because it implements Iterator it inherits take, map, filter, zip and the rest at no extra cost. Note that next returning Some forever makes this infinite, and take(6) is what bounds it.

Nothing in Rust does this. An iterator's next takes no argument, so the flow is one-way; the replacements are an object whose methods carry the conversation, as above, or a pair of channels between two threads. Both columns print the same four lines, and the Rust version needed a hand-built state machine to do it. This is the honest cost of no generators, not a spelling you have not found yet.

join() waits for a thread and hands back what its closure returned, which is why the output is in spawn order even though the work was not. The interesting part is what makes this safe: the ownership rules from the second section are the same rules that prevent data races, because a value moved into a thread cannot still be reachable outside it. That is what "fearless concurrency" refers to — not a library, but the borrow checker applied to threads.

The drop(sender) is load-bearing: the receiver's iterator ends when every sender is gone, and the original would otherwise stay alive and hang the program. The sort is honest rather than cosmetic — with three real threads the arrival order varies between runs, which is exactly the class of nondeterminism a single-threaded Lua state never exposes you to. For shared mutable state instead of messages, the pair is Arc<Mutex<T>>: the thread-safe sibling of the Rc<RefCell<T>> from the Ownership section.

A Rust mod declares a namespace and returns nothing; use only shortens paths, so use math_helpers::double; would let you write double(21). Files do come into it — mod math_helpers; with no body tells the compiler to look in math_helpers.rs — but the module tree is built by those declarations rather than inferred from the directory, which is why a new file that nothing declares is silently not compiled.

Private is the default and pub is the opt-in, which is the inverse of most languages and matches Lua's habit of returning a small table from a big file. The graduations are worth knowing when a project grows: pub(crate) is visible throughout your own crate but not to anyone depending on it, and pub(super) only to the parent module. A crate is the unit of compilation and of publication, and Lua has no counterpart to it at all.

LuaRocks installs into a shared tree that the interpreter finds through package.path, so which version you get depends on the machine. Cargo writes the requirement into Cargo.toml and the resolved version into Cargo.lock, both checked in, so cargo build reproduces the same dependency graph anywhere — and the same tool also runs your tests, builds your docs, formats your code and publishes your crate. Neither column runs here: neither package is available to the browser runner, and the Rust one is the reason this page stays inside the standard library.

This is an extension trait, and it is governed by the orphan rule: you may implement your own trait for anyone's type, or anyone's trait for your own type, but never someone else's trait for someone else's type. That is what makes it impossible for two libraries to define conflicting behavior for str — a class of breakage the Lua column invites, which is exactly why Lua libraries are told not to touch the shared metatable. The method is also only visible where Shout is in scope, so importing it is a local decision rather than a global mutation.

Neither column names a width, and for Lua that is the point: math.maxinteger is whatever the interpreter was compiled for. A desktop build gives you 64-bit integers, and builds for smaller targets give 32-bit ones — so the same literal can be an integer on one machine and, being too large for the build, silently a float on another. Rust puts the width in the type name, so i32 means the same thing everywhere and the only question left is what happens at the boundary. Its answer: the bare + panics in a debug build and wraps in a release build, so an overflow a test caught can go quiet in production. The alternatives all state their intent — wrapping_add, checked_add returning an Option, saturating_add clamping at the limit, and overflowing_add returning both.

Every conversion is written: as for a numeric cast, parse for text, into() for a widening that cannot lose information. It is more typing, and it removes the whole family of bug where a value became a float three functions ago and a comparison has quietly been approximate ever since. Note the division too: Lua 5.3 made / always produce a float and added // for floor division, where Rust reads the operand types — so 7 / 2 is 3 in Rust and 3.5 in Lua.

A Rust String owns a growable buffer, so push_str appends in place and there is nothing to detour around — the same reason C# reaches for a StringBuilder and Rust does not. This is the clearest single consequence of the two string types: &str is immutable like every Lua string, and String is the mutable one Lua has no equivalent of.

Two pieces of ceremony, each earning its place. move is required because the closure outlives the iteration that created it, and since i32 is Copy the capture is a copy. Box<dyn Fn() -> i32> is required because every closure has its own anonymous type, so three of them will not sit in one Vec without being boxed behind a trait object. A Lua table of functions needs neither, and pays for it with a pointer chase and a collector.

Lua special-cases strings and compares everything else by identity, so two empty tables are not equal. In Rust == is the PartialEq trait, and every standard collection implements it by comparing contents — so two empty Vecs are equal, and so are two HashMaps with the same entries. Comparing identity is the thing you have to ask for, with std::ptr::eq. This is also why the derive list in the Traits section matters: a struct without PartialEq cannot be compared with == at all.