Go.CodeCompared.To/Rust

Both languages center on a main function, but Rust needs no package clause or import for basic output. println! is a macro (the ! marks it), not a function — it expands at compile time and type-checks its format string, so a mismatched placeholder is a compile error rather than a runtime surprise.

Rust's cargo is the counterpart to the go tool: cargo run mirrors go run, and cargo build --release mirrors go build. Both compile to a single native binary with no runtime to ship. The big difference is dependencies — Cargo pulls libraries (crates) from crates.io, where Go modules are fetched directly from their version-control URLs.

Rust shares Go's // and /* */ comments and adds a documentation form: /// comments attach to the following item and are rendered by cargo doc into HTML, much like Go's convention of a comment immediately above a declaration, but with first-class tooling and Markdown support.

Rust's use brings a path into scope much like Go's import, but it pulls in a specific item (a type, function, or module) rather than a whole package, and you then refer to it by its short name. The standard library is the std crate; unlike Go, common collections like HashMap are not built-in keywords and must be brought in with use.

This is a core mindset shift from Go. A Rust let binding is immutable by default — reassigning it is a compile error unless you opt in with let mut. Go variables are always mutable; Rust makes mutability visible and deliberate, which the compiler then uses to reason about aliasing and thread safety.

Rust lets you shadow a name by declaring it again with let, even changing its type — here value goes from &str to i32 while reusing the name. Go forbids redeclaring a variable in the same scope, so a type change requires a fresh name. Shadowing keeps temporary transformations from cluttering the namespace.

Both infer types from initializers, but Rust's inference is whole-function: it can deduce a variable's type from how it is used later, not just from its initializer. Where Go's := infers only from the right-hand side, Rust may leave a type open until a downstream call pins it down.

A Rust const must have an explicit type annotation and is inlined at every use, evaluated at compile time. Go constants can be untyped and take their type from context; Rust constants are always typed. The naming convention (SCREAMING_SNAKE_CASE) matches Go's exported-constant style.

This is the defining difference. In Go, assigning a slice copies the header so both names share one GC-managed backing array. In Rust, assigning a Vec moves ownership: numbers is no longer usable, and the data is freed exactly once when other goes out of scope — no garbage collector, no double free, enforced at compile time.

A &T is a borrow — temporary read access that does not take ownership. Passing &numbers lets sum read the vector while the caller keeps it. Go shares everything freely and lets the GC sort out lifetimes; Rust makes the borrow explicit and the compiler proves the data outlives every reference to it.

A &mut T is an exclusive mutable borrow: Rust allows only one at a time and no shared &T while it is alive. That single rule eliminates data races at compile time. The *number dereference writes through the reference. Go lets any number of aliases mutate the same slice and trusts you to synchronise access yourself.

Both slice with a half-open range. A Go slice is a view that shares (and can grow back into) the backing array. A Rust &[T] is a borrow of a contiguous region, and the borrow checker forbids mutating numbers while middle is alive — so a slice can never outlive or dangle past the data it views.

Go has one string type — an immutable byte view. Rust splits the idea in two: &str is a borrowed, fixed-size view (string literals are &'static str), while String is a growable, heap-owned buffer. You convert with to_string() or String::from, and a &String coerces to &str automatically when passed to functions.

Rust's println!/format! macros mirror Go's Printf/Sprintf, but the format string is checked at compile time and you can interpolate a variable inline as {name}. A missing argument or wrong type is a compile error, never Go's runtime %!s(int=...) output.

Rust calls these as methods on the &str itself, like Go's strings package but member-style. split returns a lazy iterator, so you collect() it into a Vec — reflecting Rust's pervasive iterator model, where nothing allocates until you ask it to.

Like Go, a Rust str is UTF-8 and len() returns bytes. Where Go reaches for the utf8 package or range, Rust offers chars() (an iterator of char) and char_indices(). Indexing a str by a single integer is deliberately a compile error, because a byte offset could land in the middle of a character.

Both have explicitly sized integers (i8/i64 mirror int8/int64) and require an explicit cast between numeric types — Rust spells it value as f64 rather than float64(value). Rust has no platform-width default like Go's int; the compiler infers i32 unless you annotate or the context demands otherwise. Underscores like 9_000_000_000 are digit separators.

Go integer overflow silently wraps. Rust checks overflow in debug builds and panics, forcing you to opt into wrapping explicitly with wrapping_add (or checked_add/saturating_add). Release builds wrap like Go for speed, but the debug-time check catches accidental overflow during development rather than letting it corrupt a result silently.

Go's strconv.Atoi returns (int, error). Rust's str::parse returns a Result and infers the target type from context (the i32 annotation here), so the same method parses into any type that implements FromStr. unwrap() extracts the value or panics — fine for a demo, but real code matches on the Result.

Rust's Vec<T> is the counterpart to a growable Go slice: heap-allocated and homogeneous. push appends in place, which is why the binding must be mut, and the element type is part of the type, so a Vec<i32> can never accidentally hold a string. The vec! macro builds one from a literal list.

Both distinguish a fixed-size array from a growable sequence: Go's [3]int and Rust's [i32; 3] bake the length into the type. In Rust the array lives on the stack with a compile-time-known length, so indexing it past the end with a constant is caught at compile time rather than panicking at runtime.

Rust's HashMap lives in std::collections rather than being a built-in keyword like Go's map. get returns an Option<&V> instead of Go's comma-ok pair, so you handle the missing-key case with if let or match — the type system makes "the key might be absent" impossible to forget.

Where Go's range yields index and value directly, Rust composes iterator adapters: iter() borrows each element and enumerate() pairs it with its index. This adapter model — map, filter, zip, take, enumerate — is how Rust expresses the loops Go writes out by hand, and it compiles to the same tight code.

In Rust if is an expression that produces a value, so you bind its result directly — there is no ternary operator because if already fills that role. Both branches must yield the same type, checked at compile time. Go's if is a statement, so it needs the separate declare-then-assign pattern.

Rust's match is Go's switch taken further: it is an expression, it matches ranges (1..=5) and patterns, and it is exhaustive — the compiler rejects the code unless every possible value is handled, which is why the catch-all _ arm is required here. There is no implicit fall-through to guard against.

Rust replaces the C-style for with for ... in over a range or iterator, and adds a dedicated loop keyword for an unconditional loop — which can even break with a value: let x = loop { break 5; };. Go folds all looping into for; Rust separates the bounded and unbounded cases into distinct, clearer constructs.

if let is Rust's shorthand for a match with a single interesting arm — it binds count only when get returns Some. It is the idiomatic replacement for Go's comma-ok pattern, and it pairs with else or with while let to handle the other shapes.

A Rust fn annotates each parameter type and the return type after ->. The final expression without a semicolon is the return value (an explicit return also works). Accepting name: &str borrows the text instead of copying it — the idiomatic way to take read-only string input.

Rust closures use |params| body and capture their environment automatically. Unlike Go's function literals, a closure's captured variables are borrowed or moved according to how they are used, and its type implements one of the Fn/FnMut/FnOnce traits — which is the mechanism by which functions accept closures generically.

Returning a closure in Rust needs impl Fn(i32) -> i32 as the return type, and move forces the closure to take ownership of amount so it outlives the function call. Go infers all of this; Rust makes both the closure's trait and its capture mode (move vs borrow) explicit in the signature.

Rust's iterator adapters give it the map/filter/fold pipeline Go's standard library lacks. filter takes a closure and sum() consumes the iterator; the whole chain is lazy and compiles down to a single tight loop with no intermediate allocation — Rust's "zero-cost abstraction" in practice.

Rust structs resemble Go's, but there are no zero values — every field must be given a value at construction — and fields are private to the module unless marked pub. The #[derive(Debug)] attribute auto-generates the {:?} formatting that Go provides through %+v.

Rust groups a type's methods in a separate impl block instead of attaching each one with a receiver as Go does. The explicit &self is a borrow of the instance — &self to read, &mut self to mutate, self to consume — so each method's access to the object is visible in its signature.

This is one of Rust's biggest additions over Go. A Rust enum is a true sum type — a value is exactly one of its variants — where Go approximates the idea with iota integer constants that carry no guarantee of being valid. A match over an enum is checked for exhaustiveness, so adding a variant forces every match to be updated.

Rust enum variants can carry data, which is how Option<usize> models "an index or nothing" without Go's (value, bool) pair or a nil pointer. The caller must unwrap the Option (via match, if let, or unwrap), so a missing value can never be silently mistaken for a real one.

A Rust trait is like a Go interface, but a type must implement it explicitly with impl Speaker for Dog rather than satisfying it structurally just by having the right method. That makes the relationship intentional, and it lets traits carry default methods and associated types that Go interfaces cannot express.

A Rust trait can supply default method bodies, so greet works for any implementer that provides name(). Go interfaces are pure contracts with no implementation, so shared behaviour there comes from struct embedding or free functions rather than from the interface itself.

The #[derive(...)] attribute auto-implements common traits — PartialEq for ==, Clone for explicit copies, Debug for {:?}. Go gives every comparable struct == and printing for free; Rust makes each capability opt-in, which is why copying needs an explicit .clone() and equality needs the derive.

A Go interface value is implicitly a fat pointer that dispatches at runtime. Rust makes that explicit: a heterogeneous collection needs Box<dyn Shape>, where dyn marks dynamic dispatch and Box gives each differently-sized value a uniform heap pointer. The default in Rust is static dispatch via generics; dyn is the opt-in for Go-style runtime polymorphism.

Rust folds Go's (value, error) pair into a single Result<T, E> enum — either Ok(value) or Err(error), never both and never neither. Because it is one value, the compiler can force you to handle the Err case (here via match), unlike Go where silently ignoring the returned err compiles cleanly.

The ? operator is Rust's answer to Go's repetitive if err != nil { return ..., err }. Applied to a Result, ? unwraps an Ok or returns the Err early from the enclosing function, collapsing the propagation boilerplate into one character while keeping it explicit at each call site.

Rust has no nil. Absence is modeled by Option<T> — Some(value) or None — so there is no null pointer to dereference by accident; the "billion-dollar mistake" is simply absent from the type system. A Go nil slice, map, or pointer can still be ranged or dereferenced, whereas a Rust None must be unwrapped before you can reach a value.

Both have panic for unrecoverable bugs, distinct from Result/error for expected failures. Rust's panic! unwinds the stack like Go's panic, and catch_unwind can intercept it — though doing so is rare and discouraged. The cultural rule matches Go's: reserve panics for "this should never happen," not for ordinary error flow.

A let ... else binding mirrors Go's if err != nil { return } guard: it pattern-matches on the happy path and binds the result in the surrounding scope, and if the pattern does not match it runs the else block, which must diverge (return, break, continue, or panic!). Unlike if let, whose binding is confined to its own block, the binding from let-else stays in scope afterward, so the rest of the function reads top-to-bottom with no extra indentation.

Rust's match destructures the tuple and binds variables in each arm — (0, y) matches any pair whose first element is 0 and captures the second as y. Go's switch has no destructuring, so the same logic becomes a series of manual index comparisons.

A match arm can carry an if guard — value if value % 2 == 0 — that adds a boolean condition on top of the pattern. Combined with bindings and ranges, guards let a single match express what Go writes as a conditionless switch with boolean cases.

Matching a data-carrying enum extracts its fields in the same step that selects the variant — Shape::Circle { radius } both confirms the variant and binds radius. This replaces Go's tag-field-plus-conditional idiom, and exhaustiveness checking guarantees every shape is handled, so a new variant cannot be silently forgotten.

Stabilised in the 2024 edition, let chains let a let pattern and ordinary boolean conditions be joined with && inside one if — the direct counterpart to Go's if value, ok := m[k]; ok && value > 10. Before 2024 this required a nested if let { if value > 10 { ... } }. Bindings introduced by an earlier link are in scope for later links, so value is usable in the comparison that follows it.

Both languages now have generics with constraints. Rust's trait bound T: PartialOrd (which supplies the > comparison) is the analogue of Go's type-set constraint int | float64, but it composes from ordinary traits and works for any ordered type without listing them — and it is monomorphised, so there is no runtime dispatch cost.

Generic structs look nearly identical: Pair<T> versus Pair[T any]. Rust infers the type argument from the values at construction (no Pair::<&str> needed here), and because generics are monomorphised, Pair<&str> and Pair<i32> compile to distinct, fully-optimised types.

To print T generically, Rust requires the bound T: Display (the trait behind {}), because nothing is printable by default — every capability is opted into through a trait. Go's any needs no such bound because fmt.Println uses runtime reflection, trading Rust's compile-time guarantees for flexibility.

Const generics let a definition be parameterized over a value — here the array length N — not just over types, something Go's generics cannot express. Because the length is part of the type and known at compile time, [i32; 3] and [i32; 5] are distinct types served by one sum, with the data living inline on the stack and no heap allocation or runtime length field.

Go's go schedules a lightweight goroutine onto its runtime; Rust's thread::spawn starts a real OS thread and returns a JoinHandle you join() to wait on. Rust threads are heavier than goroutines and need no runtime, and crucially the spawned closure's captures are checked for thread-safety at compile time.

Rust's std::sync::mpsc gives Go-style channels: send() pushes, and iterating the receiver yields values until every sender is dropped (the move closure takes the sender, so the loop ends when the thread finishes). The name means "multiple producer, single consumer," but the share-by-communicating model is the same as Go's.

To share state across Rust threads you wrap it in Arc<Mutex<T>> — Arc is an atomically reference-counted pointer (each thread owns a handle) and Mutex guards the data. The compiler refuses to share anything not proven thread-safe, so the lock is not optional discipline as in Go but a requirement to even reach the value.

A Rust JoinHandle<T> carries the thread's return value, so collecting each handle.join() gathers the results with no shared mutable slice and no WaitGroup. The move closure takes ownership of number, and the auto-derived Send trait on i32 is what lets the compiler prove the value may safely cross the thread boundary.

An async fn returns a Future — a value that does nothing until it is polled, which .await drives to completion. This is the opposite of a Go goroutine, which the runtime starts and schedules eagerly. Rust deliberately ships no built-in executor in std, so a future needs a runtime such as tokio to actually run; the few lines of block_on here are a minimal stand-in that polls one future on the current thread. The payoff is that async tasks are cheap state machines with no per-task stack.