JavaScript.CodeCompared.To/Rust

In Rust, variables declared with let are immutable by default — reassigning them after the first assignment is a compile error. This maps to JavaScript's const, not let. The Rust compiler enforces immutability at compile time, and idiomatic Rust code is primarily immutable: mutation is the exception, not the rule.

The mut keyword declares a mutable binding — the exact equivalent of JavaScript's let. Without mut, an attempt to change the value is a compile-time error. The mut keyword makes mutation visible in the code, signaling to readers that this variable's value will change. Idiomatic Rust reaches for mut only when mutation is genuinely required.

Rust infers types from the literal value just as JavaScript does, but Rust's inference is at compile time and fixes the type permanently. Unlike JavaScript's single number type, Rust distinguishes integer types (i8, i32, i64, u8, u32, etc.) and floating-point types (f32, f64). The defaults when unspecified are i32 for integers and f64 for floats. JavaScript's typeof inspects the runtime type; in Rust the type is always known at compile time.

Rust type annotations follow the variable name with a colon — the same syntax as TypeScript. While Rust's type inference usually makes annotations optional, they are required when the compiler cannot determine the type from context. Rust uses snake_case for variable names (unlike JavaScript's camelCase), and the compiler emits a warning for names that violate the convention.

Rust's const declares a compile-time constant — the type annotation is required, and the value must be a constant expression computable at compile time. Unlike JavaScript's const (a block-scoped runtime binding), Rust's const is inlined at every use site during compilation. Constants are conventionally named in SCREAMING_SNAKE_CASE in both languages. Rust also has static for module-level variables that have a fixed memory address rather than being inlined.

Rust allows re-declaring a variable with the same name in the same scope — called shadowing. Each let creates a new binding that hides the previous one. Unlike reassigning a let mut variable, shadowing can also change the type (as shown above: &str → i32). JavaScript has no equivalent because a second const or let declaration with the same name in the same scope is a syntax error. Shadowing is idiomatic in Rust for transformation chains that naturally reuse the same conceptual name.

Rust's ownership model means that assigning a heap-allocated value (like a Vec) to another variable moves ownership — the original variable can no longer be used. This is fundamentally different from JavaScript, where object assignment copies a reference so both variables share the same underlying data. Rust's move semantics prevent two places from owning the same heap memory, guaranteeing memory safety without a garbage collector. For stack-allocated types like integers, assignment copies the value automatically (they implement the Copy trait).

Rust requires an explicit .clone() call to deep-copy a heap-allocated value. Unlike JavaScript's spread ([...arr]) or Object.assign(), which are syntactic sugar, Rust's clone() makes the performance cost of copying visible in the source code — developers are always aware when an allocation occurs. For types like integers and booleans that implement the Copy trait, assignment automatically copies the value without any clone() call.

The & prefix creates a reference (a borrow) — the function reads the value without taking ownership. JavaScript always passes objects by reference implicitly; Rust makes the reference explicit with & at both the call site (&greeting) and the parameter type (&String). After the function returns, ownership stays with the caller. Multiple immutable borrows can coexist simultaneously — Rust allows any number of &T references as long as no mutable reference exists at the same time.

A mutable reference (&mut) allows a function to modify the caller's value. Rust enforces an exclusive-access rule: at any given moment, a value may have either one mutable reference or any number of immutable references — never both simultaneously. This rule, enforced at compile time, eliminates data races entirely. In JavaScript, any function receiving an object can mutate it freely, with no mechanism to prevent accidental mutation — a common source of subtle bugs in larger codebases.

Rust types that are cheap to copy (integers, floats, booleans, chars, and fixed-size tuples of these) implement the Copy trait. When a Copy type is assigned to another variable, the value is duplicated on the stack — ownership is not moved. This matches JavaScript's behavior for primitive values (number, boolean). Heap-allocated types like String and Vec do not implement Copy because copying them requires an allocation — use .clone() for an explicit copy, or & to borrow.

Rust has two string types: &str (a string slice — a borrowed view of UTF-8 bytes, usually pointing into static memory or a String) and String (an owned, heap-allocated, growable string). JavaScript has a single string type that is always immutable. Function parameters usually accept &str because a &str can refer to both string literals and slices of String values, making it the more flexible choice for read-only string arguments.

Rust's format!() macro is the equivalent of JavaScript's template literals — it creates a new String with interpolated values using {} as the placeholder (or {variable_name} in Rust's inline capture syntax). String concatenation with + in Rust works only for String + &str and is less ergonomic, so format!() is generally preferred. The .join() method on slices works exactly like JavaScript's Array.join().

Rust's string methods closely mirror JavaScript's. The main naming differences are to_uppercase() and to_lowercase() instead of toUpperCase() and toLowerCase(), and contains() instead of includes(). Rust strings are guaranteed to be valid UTF-8; indexing by byte position rather than character is a common source of beginner confusion. Use .chars().nth(n) for Unicode-correct character access rather than string[n].

Rust's .split() returns a lazy Split iterator rather than an array. To get a Vec, you must call .collect() at the end — the type annotation Vec<&str> tells collect() what to build. This design is intentional: if you only need to iterate over the parts once (e.g., in a for loop), allocating a full Vec is wasteful. The "lazy by default, collect when needed" pattern appears throughout Rust's iterator API.

Rust's format specifiers go inside the curly braces: {:.2} for two decimal places (like toFixed(2)), {:05} for zero-padded width, {:>10} for right-alignment. The {:?} Debug format produces output similar to JSON.stringify() for simple types and is available on any type that derives or implements the Debug trait. The {:#?} variant produces pretty-printed, indented output useful for nested data structures.

Rust's .parse() is generic — it returns a Result<T, E> that is either a successfully parsed value or a parse error. The type annotation on the binding (let parsed: i32) tells Rust what type to parse into. The .unwrap() call extracts the value and panics if parsing fails — convenient for examples, but production code handles the error with pattern matching or the ? operator. JavaScript's parseInt silently returns NaN on failure; Rust returns an Err variant that the type system forces you to handle.

Rust's Vec<T> is the equivalent of a JavaScript array — a dynamically-sized, heap-allocated sequence. The vec! macro creates a Vec from literal values. push() adds to the end; pop() removes and returns the last element as an Option<T>. The .len() method replaces JavaScript's .length property. Indexing with [] panics if out of bounds; the safer .get(index) returns Option<&T> instead. A Vec must be declared mut to allow modification.

Rust's HashMap<K, V> is the equivalent of JavaScript's Map. It requires use std::collections::HashMap. The .get(key) method returns Option<&V> — either Some(&value) or None — rather than returning undefined for missing keys as JavaScript does. This forces explicit handling of the missing-key case. The .entry(key).or_insert(default) pattern is idiomatic for "insert if absent, then modify," and is more efficient than a separate contains + insert because it performs only one hash lookup.

The .entry(key).or_insert(default) pattern inserts a default value if the key is absent, then returns a mutable reference to the stored value. Modifying the value requires dereferencing with *count += 1 because or_insert returns a &mut V. This single-call pattern is more efficient than JavaScript's (map.get(key) ?? 0) + 1 followed by map.set(key, newValue), because it performs only one hash lookup instead of two.

Rust's Vec has .contains(&value) (note the &), .sort() (in-place), .dedup() (removes consecutive duplicate elements — call after sorting for uniqueness), and .retain(predicate) for in-place filtering. JavaScript's .sort() mutates the original array by default; Rust's .sort() also mutates in place, which is why sorted = numbers.clone() is used above to preserve the original. The Set uniqueness pattern in JavaScript corresponds to sorting and then calling .dedup() in Rust.

Rust has first-class range syntax: 1..5 is exclusive-end (1, 2, 3, 4) and 1..=5 is inclusive (1, 2, 3, 4, 5). Ranges are lazy iterators — they allocate no memory until consumed with .collect() or a for loop, so 1..1_000_000 is cheap to create. JavaScript has no built-in range syntax; the common workaround allocates a full array immediately. Ranges also work as slice indices: &vec[1..3] gives a view of elements 1 and 2.

Const generics let a definition be parameterized over a value — here the array length N — not just over types. JavaScript has no such notion: every array is dynamically sized and length is a runtime property. Because the length is part of the Rust type and known at compile time, [i32; 3] and [i32; 5] are distinct types served by one sum, stored inline with no heap allocation. (For a growable, JS-array-like sequence you would reach for Vec<T> instead.)

In Rust, if/else is an expression that produces a value — there is no separate ternary operator ? :. All branches must produce the same type; the compiler enforces this. The else branch is required whenever the if expression is used as a value, because the compiler must guarantee a value for every code path. The last expression in each block is its return value — no explicit return keyword is needed.

Rust's while loop is syntactically identical to JavaScript's, without parentheses. Rust's for item in collection corresponds to JavaScript's for (const item of collection). Iterating with for color in &colors borrows the Vec (leaving colors accessible afterwards); for color in colors moves the Vec into the loop, consuming it. Rust also has a bare loop { } that runs forever until a break, which is idiomatic for retry loops and state machines.

Rust's loop is unique: break value causes the entire loop expression to evaluate to that value. This allows loops to be used as expressions, avoiding the need for a mutable outer variable that is set inside the loop and read outside. In JavaScript, the closest equivalent is an immediately-invoked function expression (IIFE) with an early return — Rust's loop { break value } is cleaner and does not require a new function scope or closure allocation.

Rust's range-based for loop is the idiomatic replacement for JavaScript's C-style for (let i = 0; i < n; i++). The 1..=5 range includes both endpoints; 1..6 excludes the end. For indexed iteration, .enumerate() produces (index, &value) tuples — analogous to JavaScript's .forEach((value, index) => { }), but note that Rust's pair has the index first, then the value.

Rust's match expression replaces JavaScript's switch statement, with key improvements: there is no fall-through between arms (no break needed), match is an expression that returns a value, and the compiler enforces exhaustiveness — forgetting to handle a case is a compile error. Multiple patterns in one arm are separated with |. The _ wildcard is the catch-all, equivalent to JavaScript's default.

Match arms can include a guard condition (if condition after the pattern), allowing arbitrary boolean expressions. The guard receives a binding of the matched value (t in this example). A match with guards behaves like an if-else if chain but integrates cleanly with Rust's pattern matching — matching on type, destructuring, and guarding can all appear in the same arm. The final _ wildcard covers all cases that no guard matches.

Rust's pattern matching supports destructuring of tuples, structs, enums, and references directly in let bindings and match arms. Unlike JavaScript destructuring (which always binds all specified positions regardless of values), Rust patterns can test values simultaneously. The pattern (x, 0) matches only when the second element is exactly 0 and binds the first to x — combining a structural test and a binding in one step.

if let combines a pattern match and a conditional — it runs the body only when the value matches the pattern, binding any names in the pattern. It is shorthand for a two-arm match where the second arm does nothing. if let Some(value) = maybe is the idiomatic way to unwrap an Option when only the Some case matters. JavaScript's null-check (if (value != null)) does not produce a new binding; Rust's if let produces a binding guaranteed to hold a non-null value inside the block.

while let loops as long as the value matches the pattern and stops when it does not. Vec::pop() returns Option<T> — Some(value) when the Vec is non-empty, None when empty. The while let Some(item) = stack.pop() loop processes items one by one until the Vec is empty, with item bound to each value in turn. This is more expressive than JavaScript's while (arr.length > 0) { const item = arr.pop(); } because the pop and the emptiness check are unified in a single pattern.

Stabilised in the 2024 edition, let chains let a let pattern and ordinary boolean tests be joined with && inside one if — and crucially the binding from the let link is in scope for the tests that follow. That makes the Rust form tighter than the JavaScript one, which needs a separate const value = ... before the if so the comparison can see it. The Some(..) pattern also distinguishes "absent" from "present", where JS leans on an undefined check. Before 2024 this needed a nested if let { if value > 10 { ... } }.

Rust functions use the fn keyword with required type annotations on all parameters and the return type (after ->). The last expression in a function body is implicitly returned — no return keyword needed (though return is valid for early exits). A semicolon on the last line makes it a statement that returns () (unit/void), causing a type error if a non-unit return type is declared. Functions default to private visibility; add pub to export from a module.

Rust closures use pipes |params| instead of JavaScript's arrow =>. When the body is a single expression, curly braces are optional and the expression is implicitly returned — analogous to JavaScript's implicit-return arrow x => x * 2. Rust can often infer closure parameter types from context, so type annotations are frequently omitted. Unlike JavaScript, where all closures capture by reference automatically, Rust closures capture by the most restrictive mode possible: by reference, by mutable reference, or by move.

Rust function types are written as trait bounds: Fn(T) -> R for an immutable closure, FnMut(T) -> R for one that mutates captured variables, and FnOnce(T) -> R for one that consumes captured values. The <F: Fn(i32) -> i32> syntax declares a generic function that accepts any callable with that signature. JavaScript treats functions as untyped values — calling a non-function silently throws at runtime. Rust catches type mismatches at compile time, without any opt-in.

The move keyword before a closure forces it to take ownership of all captured variables. This is necessary when the closure outlives the scope where the captured variables were defined — for example, when returning a closure from a function or sending one to another thread. In JavaScript, closures always capture the surrounding scope by reference implicitly, keeping captured variables alive; Rust's move is the explicit equivalent that transfers ownership. The impl Fn(i32) -> i32 return type says "some type that implements Fn" without naming the concrete closure type.

Rust does not have default parameter values. The common idiom is to accept Option<T> for optional parameters and use .unwrap_or(default) to supply the default inside the function. Another pattern is a builder struct (for many optional fields) or separate functions with descriptive names. While more verbose than JavaScript's param = default syntax, the Option approach makes the optionality visible in the type signature, which is especially useful for library APIs.

Rust has no class keyword. Data is defined in a struct, and behavior is added separately in an impl block. Struct fields are accessed with dot notation, identical to JavaScript class instances. Initialization uses FieldName: value syntax — all fields must be provided (there are no default field values unless you implement the Default trait). There is no new keyword; constructors are associated functions conventionally named new but treated no differently from any other function.

Methods are defined in an impl block attached to a struct. The first parameter &self is the receiver — analogous to JavaScript's this, but explicit and typed. &self borrows the struct immutably; &mut self borrows it mutably (required for methods that modify fields); plain self consumes it. A struct can have multiple impl blocks, which is useful for organizing methods or adding trait implementations separately.

Functions in an impl block that do not take self as a parameter are called associated functions — the equivalent of JavaScript's static methods. They are called with double-colon syntax (User::create()). The conventional name for a constructor-style associated function is new, though Rust has no special-casing for it. JavaScript's new MyClass() calls the constructor; Rust's MyStruct::new() calls an ordinary associated function that returns a value of the struct type.

The #[derive(...)] attribute automatically generates implementations of common traits: Debug enables {:?} printing (like JSON.stringify()), Clone enables .clone(), and PartialEq enables == and != based on field values. Rust's == on custom types uses structural equality only when PartialEq is derived or implemented — without it, the compiler refuses to compile ==. In JavaScript, === always compares objects by reference identity, not by value.

Rust's struct update syntax (..existing) copies the remaining fields from an existing instance — similar to JavaScript's object spread ({ ...obj, overrides }). One important difference: the update syntax moves non-Copy fields (like String) out of the original struct, so the original becomes partially moved and inaccessible afterward. To avoid this, clone the original first. Fields listed before .. take precedence over the copied fields.

Rust traits define a set of methods a type must implement — similar to TypeScript interfaces. Unlike JavaScript (which has no static interface mechanism), Rust traits are enforced at compile time: implementing a trait incorrectly is a compile error. A struct can implement multiple traits. Trait methods that are missing from an impl block cause the compiler to list exactly which methods need to be added. Traits can also provide default method implementations, allowing partial reuse without a class hierarchy.

Trait methods can have default implementations that are inherited automatically by types that do not override them. Only the required methods (those without a body) must be provided in each impl block. Default methods can call other trait methods, including required ones — the warn and error defaults both delegate to self.log(), which each implementor supplies. This is the primary mechanism for code reuse in Rust, replacing class inheritance.

Implementing std::fmt::Display for a custom type enables {} formatting and automatic .to_string() — the equivalent of implementing toString() in JavaScript. The fmt method writes formatted output into a Formatter using write!. Once Display is implemented, the type works in all format strings, in println!, and anywhere a human-readable string representation is expected.

dyn Trait creates a trait object — a pointer to a value of any type implementing the trait, with method dispatch resolved at runtime. This is Rust's equivalent of JavaScript's duck typing. The alternative, generics (<S: Shape>), resolves at compile time (monomorphization) and generates separate machine code per concrete type, which is faster but increases binary size. Trait objects are the right choice when the concrete type is not known at compile time, such as in a mixed collection of shapes. Box<dyn Trait> heap-allocates the value so its size is uniform.

Rust enums can carry data in each variant — a feature absent from JavaScript's Object.freeze() enum pattern. The enum Shape cleanly expresses "a Shape is either a Circle with a radius, or a Rectangle with a width and height." Pattern matching destructures the variant's data simultaneously with the type check, and the compiler enforces exhaustiveness — forgetting to handle a variant is a compile error. This replaces JavaScript's tagged union (if (obj.type === "circle")) with a type-safe, exhaustive mechanism.

Rust's Option<T> is an enum with two variants: Some(value) for a present value and None for absence — there is no null or undefined. A function returning Option<String> communicates to callers that the result may be absent, and the type system forces them to handle both cases. This eliminates the JavaScript "billion-dollar mistake" of null silently propagating through code. JavaScript's optional chaining (?.) and nullish coalescing (??) exist precisely to work around the implicit nullability of every value.

Option<T> has a rich set of methods for chaining transformations without explicit null checks. .map(fn) applies a function to the inner value if Some, leaving None unchanged. .and_then(fn) is "flat map" — the function returns an Option, preventing Some(Some(x)) double-wrapping. .unwrap_or(default) extracts the value or returns a default, equivalent to JavaScript's ?? default. These methods enable chaining operations on nullable values without nested null checks, but with the type system enforcing every possible absent-value case.

In Rust, enums can have impl blocks just like structs — methods are added to the enum type directly. The match self { ... } pattern inside an enum method handles every variant, and the compiler enforces exhaustiveness. Adding a new variant to the Rust enum immediately causes compile errors in every match that does not handle it, making refactoring safe. This is a significant advantage over JavaScript's equivalent chain of if/else if checks on string values.

Rust's Result<T, E> enum encodes either a successful value (Ok(T)) or an error (Err(E)) in the return type itself — the type system forces callers to acknowledge that the function can fail. JavaScript's throw/catch mechanism allows errors to propagate silently through any number of call stack layers without appearing in function signatures. A caller can call a throwing JavaScript function without any try/catch and the compiler will not warn them. In Rust, ignoring a Result produces a compiler warning, and using the value without handling the error case is a type error.

The ? operator short-circuits on Err — it is syntactic sugar for returning early with the error if the value is Err, or unwrapping the Ok value to continue. A function using ? must return Result (or Option). This makes error propagation explicit and visible: a line with ? is a clear "this can fail and return early" marker, unlike JavaScript's await where any awaited expression can throw without any visual indicator at the call site.

A Rust panic! terminates the current thread with a message and backtrace — similar to an uncaught exception that crashes the process. Direct Vec indexing with [] panics on out-of-bounds, whereas JavaScript returns undefined silently. The safe alternative is .get(index), which returns Option<&T>. The Rust philosophy: use Result for expected failure modes (user input errors, missing files) and panic! for logic bugs that indicate the program is in an invalid state it was never designed to handle.

Custom error types in Rust are typically enums with variants for each failure mode, carrying different data per variant rather than relying on a class hierarchy. Implementing std::fmt::Display provides human-readable messages; #[derive(Debug)] provides diagnostic output. The combination gives the type full formatting support. Implementing std::error::Error marks it as an error type, enabling interoperability with error-handling libraries like anyhow and thiserror from the Rust ecosystem.

Result<T, E> has methods mirroring those of Option<T>: .map(fn) transforms the Ok value if present; .map_err(fn) transforms the Err value; .and_then(fn) chains a fallible operation; .unwrap_or(default) extracts Ok or returns a default. Note that parsing to u32 automatically rejects negative inputs (since unsigned integers cannot be negative), cleanly expressing "must be a non-negative integer" at the type level. This is a small example of how Rust's type system can encode constraints that would require manual validation in JavaScript.

A let ... else binding is Rust's built-in version of the JavaScript "guard and bail" pattern (if (Number.isNaN(number)) return;). It pattern-matches on the success value and binds it in the surrounding scope; if the match fails it runs the else block, which must diverge (return, break, continue, or panic!). Where JS's Number("abc") silently yields NaN and hopes you check, Rust's parse returns a Result the compiler forces you to handle, and let-else keeps the happy path flat and the binding in scope.

Rust's iterator adapters (filter, map, take, etc.) are lazy — no computation happens until a consuming method like .sum(), .collect(), or a for loop forces evaluation. JavaScript's array methods are eager: each call processes the entire array and allocates a new intermediate array. Rust's lazy iterators process elements one at a time through the entire chain with no intermediate allocations, which is more cache-friendly and memory-efficient. The .copied() call converts &i32 references to i32 values early in the chain.

.collect() consumes an iterator and assembles the results into a collection — the type annotation (Vec<String>) tells it what to build. Beyond Vec, .collect() can also produce HashMap, HashSet, and String. Specialized consumers like .sum(), .product(), .min(), and .max() are more idiomatic than fold(0, |acc, item| acc + item) when they apply. Calling collect() is always necessary because Rust iterators are lazy and do no work unless consumed.

Rust's iterator adaptor library is extensive. .take(n) yields the first n elements (like .slice(0, n)); .skip(n) skips the first n (like .slice(n)); .enumerate() adds an index; .zip(other) pairs elements from two iterators. Unlike JavaScript's equivalent array methods, these allocate no intermediate memory — they are lazy adapters that transform elements one at a time. Calling .take(2) on an infinite range (0..)) is perfectly safe and efficient in Rust.

.flat_map(fn) applies a function that returns an iterator to each element and flattens the results — equivalent to JavaScript's .flatMap(). In the example, splitting each sentence returns a Split iterator, and flat_map merges all those iterators into a single stream of words. The .copied() call in the second chain converts &&str (a reference to a reference) to &str, a common step needed when using .iter() on a Vec<&str>.

Rust's iterator methods find, any, all, and position correspond directly to JavaScript's find, some, every, and findIndex. The Rust variants return Option: find returns Option<&T> (not undefined) and position returns Option<usize> (not -1). Both any and all short-circuit — any stops at the first true match, and all stops at the first false — identical to JavaScript's behavior.

Rust's use statement brings items from a module path into the current scope — equivalent to JavaScript's named import (import { PI } from "./math"). Without use, items must be referred to by their full path (std::collections::HashMap::new()). Rust's standard library (std) is automatically available without installation. Third-party libraries (crates) are added to Cargo.toml and downloaded by cargo build — cargo serves the same role as npm.

In Rust, items are private to their module by default — adding pub is required to make them accessible from outside. This is the same concept as JavaScript's export, just expressed differently (opt-in public vs. opt-in export). The mod keyword defines an inline module; in production code, a separate file whose name matches the module is more common (mod math; loads math.rs). The double-colon :: is the path separator, replacing JavaScript's slash-based import paths.

Rust's build tool and package manager is cargo — the equivalent of npm and a bundler combined. Dependencies are listed in Cargo.toml with semantic version requirements; cargo build downloads and compiles them into native machine code. The crates ecosystem (crates.io) is Rust's equivalent of npm. Unlike npm, Cargo compiles all dependencies — there is no runtime module loading. The Rust standard library is intentionally lean; many things JavaScript includes by default (HTTP, regex, async runtimes) are separate crates in Rust.

Rust uses OS threads that truly run in parallel on multiple CPU cores. JavaScript is single-threaded — concurrency is achieved through the event loop and async/await, while parallelism requires separate Worker threads that share no objects and communicate only by message passing. Rust threads can share memory directly, but the borrow checker enforces that all shared data is protected by synchronization primitives. The join() call waits for the thread to complete and returns a Result (the thread might have panicked). If the code compiles, it is guaranteed free of data races.

Rust's std::sync::mpsc (multiple-producer, single-consumer) channels work similarly to JavaScript's postMessage: one end sends values, the other receives them. Unlike JavaScript Worker threads, which always serialize data (converting to and from a structured-clone representation), Rust channels move ownership of values between threads — no copying for types that do not implement Copy. The receiver can be iterated with a for loop, which blocks until the channel closes (all senders are dropped).

Arc<T> (Atomic Reference Counted) is a thread-safe reference-counted pointer — it frees the value when all references are dropped, just like a garbage collector, but using atomic operations instead of a runtime. Mutex<T> wraps a value and requires acquiring a lock before accessing it, preventing data races. The combination Arc<Mutex<T>> is the standard Rust pattern for shared mutable state between threads — analogous to JavaScript's SharedArrayBuffer + Atomics, but ergonomic and type-safe. Failing to lock (or dropping the lock early) is a compile error or a deliberate choice, not a silent race condition.

Both languages use async/await, but they differ in one telling way. A JavaScript async function is eager — calling it starts the work immediately and hands back a Promise the event loop will settle. A Rust async fn is lazy — calling it just builds a Future that does nothing until something polls it, which .await does. JavaScript has the event loop baked into every runtime, so main() just runs; Rust's std ships no executor, so production code adds a runtime such as tokio. The tiny block_on here stands in for that, polling one future to completion.