Rust.CodeCompared.To/Go

Go uses fmt.Println where Rust uses the println! macro. In Go, fmt is an explicit import from the standard library — no implicit prelude. The package main declaration and the func main() entry point are mandatory for an executable program; missing either is a build error.

Both languages ship a single tool that handles building, testing, formatting, and dependency management. Go's go fmt is opinionated and non-configurable — there is no style debate, only one canonical format. Cargo uses Cargo.toml (TOML) for manifest and Cargo.lock for reproducible builds; Go uses go.mod and go.sum. Go compiles substantially faster than Rust for most programs.

Go uses C-style %s, %d, %f format verbs in fmt.Printf, while Rust uses positional {} placeholders. Go's %v is the universal verb — it formats any value in a default way, similar to Rust's {:?}. fmt.Sprintf returns a formatted string (like Rust's format!). fmt.Fprintf writes to any io.Writer, like os.Stderr. % in a format string must be doubled as %% in both languages.

Go's := short variable declaration infers the type and declares the variable in one step — equivalent to Rust's let with inference. Go's default integer type is int (platform-sized, typically 64-bit), while Rust defaults to i32. The := syntax is only valid inside functions; package-level variables require the var keyword with an explicit type.

In Rust, bindings are immutable by default and you must write let mut to allow mutation — a key safety guarantee that prevents accidental modification. Go has no equivalent: every local variable is mutable after declaration. Package-level const is compile-time constant in both languages, but Go has no way to declare an immutable local binding. Coming from Rust, this feels like losing a safety net.

Go's integer types mirror Rust's naming but drop the prefix: int8, int16, int32, int64, uint8, … vs Rust's i8, i16, i32, i64, u8, …. Go's int is the general-purpose type (like Rust's isize); Rust defaults to i32. Go has byte (alias for uint8) and rune (alias for int32, for Unicode code points). Both languages allow digit separators: 1_000_000.

Go guarantees every variable is initialized to its type's zero value on declaration — there are no uninitialized variables and no undefined behavior from reading them. Rust achieves the same safety differently: it is a compile-time error to read a variable before assigning it. Go's zero values (0, 0.0, "", false, nil) are idiomatic and relied upon — a var counter int counter starts at zero without an explicit = 0.

Go pointers use the same & and * syntax as Rust references, but there is no borrow checker, no lifetimes, and no exclusivity rules. Multiple goroutines can hold pointers to the same value — the compiler does not prevent data races (use sync.Mutex or channels instead). Go has no pointer arithmetic; unsafe pointer casting requires the unsafe package. Go pointers are garbage-collected, so there is no use-after-free.

Both languages require explicit type conversions — no implicit numeric coercion. Go's syntax is T(expr) (a function-call-like cast), while Rust uses the as keyword. Overflow behavior differs: Rust's as truncates for narrowing casts; Go panics in debug mode for out-of-range conversions to smaller integer types. Neither language has Rust's try_from checked conversion in the standard library — Go callers handle range errors manually.

Rust has two string types: &str (borrowed slice, no allocation) and String (owned heap buffer). Go has one: string, which is immutable and internally a pointer+length pair, similar to &str. String operations in Go that produce new strings always allocate a new value. There is no distinct "owned string" type — concatenation or formatting creates a new string directly.

In Rust, string methods are called on the value directly (text.trim(), text.contains()). In Go, string operations are free functions in the strings package — strings.TrimSpace, strings.Contains, strings.ReplaceAll. Go's len(s) returns the number of bytes, not Unicode characters; use utf8.RuneCountInString(s) for character count.

Both Split and Join live in Go's strings package as free functions, while Rust provides them as methods on the str and slice types. Go's strings.Split always returns a []string — unlike Rust's split, which returns a lazy iterator that must be .collect()ed. fmt.Println with a slice prints [one two three], not the Rust debug format ["one", "two", "three"].

Rust's .chars() iterator yields Unicode scalar values (Rust's char). Go's for _, r := range string also yields Unicode code points (rune, alias for int32) with their byte index. In both languages, len returns byte count, not character count. Go's utf8.RuneCountInString gives character count, like Rust's .chars().count(). The blank identifier _ discards the byte index.

Go and Rust both have fixed-size arrays with the size as part of the type. Rust writes [i32; 5] (type then size); Go writes [5]int (size then type). Go arrays are values — assigning one copies the entire backing array. In practice, Go code rarely uses fixed arrays directly; slices ([]T) are the idiomatic choice, equivalent to Rust's Vec<T> or &[T].

Go's []T slice is the closest equivalent to Rust's Vec<T> or &[T]. A slice is a (pointer, length, capacity) triple. Growing with append may allocate a new backing array if capacity is exceeded — the slice header returned by append may point to new memory, so always reassign: numbers = append(numbers, value). Slicing with [1:4] shares the backing array; modifying a sub-slice modifies the original, which differs from Rust's non-overlapping borrow rules.

Go's map[K]V is a built-in type — no import needed. Map literals use map[K]V{ key: value } syntax. Lookup returns two values: value, ok := m[key] — the ok-idiom is idiomatic Go for checking presence, unlike Rust's Option. Accessing a missing key returns the zero value for V (not a panic); this silently introduces bugs if you forget to check ok.

Go's range over a slice yields two values per iteration: the index and a copy of the element. The blank identifier _ discards the index when only the value is needed. Unlike Rust's iter().enumerate(), there is no separate method call — range always provides the index. For maps, range yields key–value pairs; for strings, it yields byte-index and rune pairs.

Go's make([]T, length, capacity) pre-allocates a slice with the given backing array size — equivalent to Rust's Vec::with_capacity. The length and capacity arguments are separate: make([]int, 0, 10) creates an empty slice with room for 10 elements, while make([]int, 5) creates a slice of five zero-initialized elements. Go has no iterator chains like map/filter/collect — use a for loop instead.

Rust treats if as an expression that yields a value from the last expression in each arm. Go's if is a statement — it cannot produce a value inline. Use a pre-declared variable and assign inside each branch. Go adds a convenient init clause before the condition (if err := call(); err != nil) that is idiomatic for error checks. Go does not require parentheses around the condition; Rust does not use them either.

Go has only one loop keyword — for — which covers all loop shapes: C-style three-clause (for init; cond; post), while-style (for condition), infinite (for {}), and range-based. Rust uses for for iterators, while for conditions, and loop for infinite loops. Go has no range expression syntax like Rust's 0..5; numeric loops require the full for i := 0; i < 5; i++ form.

Go's switch and Rust's match both check conditions without fall-through by default (unlike C). Key differences: Go switch is a statement (cannot produce a value inline); Rust match is an expression. Go uses commas to separate case alternatives (case 2, 3:) where Rust uses |. Go has no range syntax in cases. A switch {} with no expression acts as a cleaner if/else if/else chain.

Both Go and Rust support labeled break and continue to target an outer loop. The syntax differs: Rust uses 'label (lifetime-style with a tick prefix), while Go uses a plain identifier before the loop with no special prefix. Go labels are written on a separate line above the for. In Go, break and continue without a label target the innermost loop, the same as Rust.

Both languages have a panic mechanism for unrecoverable programmer errors. Go adds recover() — a function called inside a deferred function that catches a panic and allows the goroutine to continue; this is how Go libraries prevent panics from escaping to callers. Rust has no equivalent to recover — a panic unwinds the stack and the thread terminates. In both languages, panics should be reserved for bugs; use Result in Rust or (value, error) in Go for expected failures.

Go function syntax is func name(param Type) ReturnType — no -> arrow. Go requires an explicit return; there are no implicit-return expressions. Adjacent parameters of the same type can share a single type annotation: func add(first, second int). Functions at the top level are always visible within the package; exported functions (visible outside the package) start with an uppercase letter.

Go has first-class multiple return values — a function can return any number of values without wrapping them in a tuple or struct. This is used heavily for the (value, error) error-handling pattern. Rust uses tuples for multiple returns: (T, U) which must be destructured on the calling side. Go also supports named return values — variables declared in the signature, used by a bare return — though this is best reserved for short functions.

Go closures use the func(params) ReturnType { body } syntax — the same keyword as named functions, just without a name. They capture variables by reference, not by value: if the outer variable changes after the closure is created, the closure sees the updated value. Rust closures with |params| syntax are more explicit about capture modes — move forces value capture. Go's function types are written as func(int) int rather than Rust's Fn(i32) -> i32 trait bound.

Go supports true variadic functions with ...T as the last parameter — the argument is received as a []T slice. Call it with a spread using slice... to pass an existing slice. Rust does not have variadic functions for user-defined code; the idiomatic alternative is a slice argument (&[T]). Rust's println! and format! are macros, not functions, which is why they accept varying argument counts.

Go struct definitions use type Name struct { ... }. Field visibility is controlled by capitalization — uppercase fields are exported (public), lowercase fields are unexported (package-private). Rust controls visibility with pub keyword per field. Go struct literals always use named fields (Point{X: 3, Y: 4}), though positional initialization is technically allowed for unexported fields — named form is strongly preferred.

Go methods are defined with a receiver before the function name: func (p Point) Method(). There is no impl block — methods can be declared anywhere in the same package. A value receiver (p Point) copies the struct, like Rust's &self but without borrowing; a pointer receiver (p *Point) allows mutation, like Rust's &mut self. Constructor functions like NewPoint are idiomatic in Go — there is no special Self::new syntax.

Go's struct embedding promotes the embedded type's fields and methods to the outer struct — dog.Name and dog.Speak() work without any delegation boilerplate. This is Go's answer to inheritance: composition with automatic promotion, not subtyping. Rust achieves the same effect with explicit delegation (implementing a trait or method that forwards to the inner field). Embedding is not subtyping in Go — a Dog is not a Animal; you cannot pass a Dog where an Animal is expected.

Go struct tags are string literals in backticks after a field declaration that carry metadata for packages like encoding/json. The json:"name" tag controls the JSON key name; omitempty omits the field when it is the zero value. This is a runtime reflection feature — the JSON package reads tags at runtime using reflect. Rust's serde crate achieves the same result at compile time via derive macros, which is faster but requires an explicit dependency.

Go interfaces are satisfied implicitly — if a type has all the methods the interface requires, it satisfies the interface. There is no impl Speaker for Dog declaration. Rust requires explicit impl Trait for Type blocks. Go's implicit satisfaction enables retroactive implementation: you can make an existing type (even one from another package) satisfy a new interface you define, without modifying the original type. This is structural typing, while Rust uses nominal typing.

Go interfaces enable dynamic dispatch through a (type, pointer) pair at runtime — similar to Rust's Box<dyn Trait>. Go does not require Box or any heap allocation for the interface value itself (though the concrete value may be heap-allocated). A Go interface variable holds a pointer to the concrete value and a pointer to the method table. Interface slices ([]Shape) are idiomatic in Go; Rust requires explicit boxing (Vec<Box<dyn Shape>>) for heterogeneous collections.

Go's any (an alias for interface{}, introduced in Go 1.18) is the universal type — any value satisfies the empty interface. The type switch (switch v := x.(type)) is Go's equivalent of Rust's downcast_ref. Go's type switch is cleaner syntactically; Rust's std::any::Any requires explicit downcast_ref calls. Overusing any sacrifices compile-time type safety in Go just as overusing dyn Any does in Rust.

Go interfaces can embed other interfaces — the resulting interface requires all methods from all embedded interfaces. This is how Go's standard library composes I/O abstractions: io.ReadWriter embeds io.Reader and io.Writer. In Rust, the equivalent is trait bounds with +: T: Read + Write. Go's embedding applies at the interface definition level, not just at the call site, which gives the composition a name that can appear in type signatures.

Rust replaces nullable values with Option<T>, and the compiler forces every call site to handle the None case — you cannot accidentally ignore the absence of a value. Go uses nil, which is the zero value for pointers, slices, maps, channels, functions, and interfaces. A nil check is idiomatic but not enforced by the compiler: forgetting to check triggers a nil pointer dereference panic at runtime. This is the most significant safety difference between the two languages.

Go's two-value map lookup value, ok := m[key] is the idiomatic way to distinguish "key absent" from "key present with zero value". Without the ok check, a missing key silently returns the zero value — 0 for integers, "" for strings. Rust's HashMap::get returns Option<&V>, so the absent case is impossible to ignore. The same value, ok pattern applies to type assertions in Go: typed, ok := value.(ConcreteType).

Go nil slices behave like empty slices for reads — len(nil_slice) is 0 and range over it is a no-op. Appending to a nil slice allocates and works correctly. Nil maps also safely return zero values on read, but writing to a nil map panics at runtime. Always initialize a map with make(map[K]V) or a map literal before writing to it. This asymmetry between slices (nil-safe for append) and maps (nil-unsafe for writes) is a common Go gotcha for Rust programmers.

Go's error handling pattern is to return (value, error) as two separate return values, check with if err != nil, and return 0, err or nil, err to propagate. Rust encodes success and failure in Result<T, E> — a sum type — and propagates with the ? operator. Go's approach is more verbose but no special syntax is required. The compiler does not force you to check the error return, making it easier to accidentally ignore failures.

Rust's ? operator propagates errors with one character; Go requires an explicit if err != nil { return 0, err } block at every fallible call site. The verbosity is intentional in Go: explicit error paths are visible in the source, and Go wraps errors with fmt.Errorf("context: %w", err) to add context at each level. %w wraps the error, allowing callers to unwrap it with errors.Is or errors.As.

Go's error is a built-in interface with one method: Error() string. Implement it on a pointer receiver and the type satisfies error — no derive macros, no trait registration. Rust requires implementing both Display and Error (and typically Debug). To access fields of a Go error, type-assert it: err.(*AppError). The standard library's errors.As(err, &target) performs an unwrapping type assertion that follows the error chain.

errors.Is(err, target) traverses the error chain (via Unwrap()) to check if any error in the chain equals the target — equivalent to checking the root cause. errors.As(err, &target) traverses the chain to find an error that can be assigned to the target type. These were added in Go 1.13 and are the correct way to inspect wrapped errors. Implement Unwrap() error on custom error types to make them chainable. Rust uses .source() on the Error trait for the same purpose.

A goroutine is started with the go keyword before a function call — no handle is returned. Goroutines are multiplexed onto OS threads by the Go runtime (typically GOMAXPROCS threads by default). They start with a ~2 KB stack that grows dynamically. Unlike Rust's thread::spawn, which returns a JoinHandle, goroutines are fire-and-forget; use sync.WaitGroup or a channel to synchronize. The Go runtime scheduler preempts goroutines cooperatively at function calls.

Go channels are typed conduits for values between goroutines. make(chan T) creates an unbuffered channel — a send blocks until a receiver is ready. make(chan T, n) creates a buffered channel. Rust's std::sync::mpsc is the equivalent but requires separate sender/receiver variables. A for value := range channel loop receives until the channel is closed. The Go philosophy is "communicate by sharing memory, not share memory by communicating" — prefer channels over mutexes for data transfer.

Go's select statement waits on multiple channel operations and executes whichever case is ready first; if multiple are ready simultaneously, one is chosen at random. It is the Go counterpart of Rust's tokio::select! macro, but built into the language without requiring an async runtime. A select with a default case is non-blocking — it runs immediately if no channel is ready.

Go's sync.Mutex protects shared data just like Rust's Mutex<T>. The critical difference is that Go's mutex is independent of the data it protects — there is nothing preventing another goroutine from accessing counter without holding the lock. Rust's Mutex<T> wraps the data inside the mutex and grants access only through a guard, making lock-bypass a compile-time error. The Go race detector (go test -race) catches data races at runtime.

Go added generics in Go 1.18. The syntax is func Name[T Constraint](param T) T where the type parameter list uses square brackets before the argument list. cmp.Ordered is a type constraint (from Go 1.21) equivalent to Rust's PartialOrd — it covers all ordered numeric types and strings. Go's constraints are interfaces; Rust uses trait bounds. Go infers the type argument at call sites, just like Rust monomorphization.

Go generic struct syntax is type Name[T Constraint] struct { ... }. Methods on a generic type reference the type parameter: func (s *Stack[T]) Push(item T). Because Go has no Option<T>, Pop returns (T, bool) — the zero value for T plus a boolean. Getting the zero value for a generic type requires var zero T; there is no Default::default() equivalent unless the constraint requires it.

Go constraints are interface types that can list specific types using the union syntax (~int | ~int64 | float64). The ~T syntax means "any type whose underlying type is T" — it allows custom types like type Celsius float64 to satisfy a ~float64 constraint. Rust uses trait bounds (T: Add + Display); Go uses interface constraints. The golang.org/x/exp/constraints package (moving into cmp/slices/maps in Go 1.21+) provides common pre-built constraints.

Rust's Drop trait provides automatic cleanup — when an owning variable goes out of scope, the destructor runs. Go has no destructor mechanism; instead, defer expr schedules a call to run when the enclosing function returns, regardless of which return path is taken (including after a panic). Placing defer file.Close() immediately after opening a file is idiomatic Go — it keeps the close physically close to the open, and the cleanup cannot be forgotten even if code is added later.

Deferred calls execute in last-in, first-out (LIFO) order — the last defer registered runs first. This matches Rust's drop order for local variables (last declared, first dropped). The LIFO order is important for paired resource management: mutex.Lock(); defer mutex.Unlock() ensures the lock is always released, and multiple locks are released in the correct reverse order to avoid deadlocks.

Go's named return values can be modified by a deferred function — the deferred closure captures them by reference. This is commonly used to add context to errors or recover from panics while still returning a meaningful error value. There is no Rust equivalent; Rust achieves similar patterns with wrapper functions or RAII guards. Named return values are idiomatic only in short functions where they improve readability; in longer functions they can be confusing.

Go 1.21 introduced the slices package with generic slices.Sort and slices.SortFunc. Before 1.21, the sort package was used with interface-based sorting. Rust's slice.sort() sorts in-place with a stable algorithm; Go's slices.Sort uses an unstable sort (faster). For stable sorting, use slices.SortStableFunc. The comparison function in SortFunc returns an int (negative, zero, positive) rather than Rust's std::cmp::Ordering enum.

Go's strconv package handles all numeric string conversions. strconv.Atoi is the common integer parser (short for ASCII to int); the more general strconv.ParseInt accepts a base and bit size. Rust's str::parse::<T>() is a single method with type inference. Go always returns an error from strconv functions rather than panicking on bad input — always check it. strconv.Itoa converts an integer to string; fmt.Sprintf or fmt.Fprintf handle more complex formatting.

Go's io.Reader and io.Writer are the foundational interfaces for streaming I/O — any type with Read([]byte) (int, error) or Write([]byte) (int, error) satisfies them. Rust uses the Read and Write traits from std::io. The implicit interface satisfaction in Go makes it easy to compose: bufio.NewWriter wraps any io.Writer, strings.NewReader wraps a string as an io.Reader — no adapter types or explicit impl declarations needed.

Go's time.Duration is an int64 of nanoseconds. Duration literals are created by multiplying a number by a named constant: 30 * time.Second. Rust's std::time::Duration has separate from_secs/from_millis constructors. Go's most distinctive design choice: time formatting uses the specific reference time Mon Jan 2 15:04:05 MST 2006 (the first second of Go's design) as a template instead of POSIX %Y-%m-%d strftime codes — "2006-01-02" means year-month-day.