Rust.CodeCompared.To/Haskell

Every Haskell program's entry point is main :: IO (), the counterpart of Rust's fn main(). The type signature IO () tells the compiler this action performs side effects and produces no meaningful result — Rust expresses roughly the same idea with an implicit () return type. putStrLn is the direct analogue of println! for a plain string.

Stack and Cabal fill the role Cargo plays for Rust — dependency management, building, testing, and running a project. Stack additionally pins an entire compiler-plus-package snapshot (an LTS resolver) so that a project builds identically on every machine, a stronger reproducibility guarantee than Cargo.lock alone provides. Most real Haskell projects use Stack or Cabal rather than invoking ghc directly.

Haskell has no built-in string interpolation, so Text.Printf.printf provides C-style formatting closer to Rust's {:.1} specifiers than plain concatenation would. hPutStrLn stderr writes to standard error, the counterpart of Rust's eprintln!. Notice that printf is polymorphic in its argument count and types — a very different mechanism from Rust's macro-based println!, but the call site looks familiar.

Rust's let is immutable by default but offers an escape hatch, let mut, for in-place mutation. Haskell offers no such escape hatch for ordinary let bindings — every binding is permanently immutable, and "changing" a value always means computing a new one under a new name. Genuine mutable state in Haskell exists only inside IO, via explicit reference types like IORef.

Rust allows repeatedly shadowing a name in the same scope, even changing its type each time, which is a common idiom for step-by-step transformations. Haskell technically allows shadowing too, but idiomatic style favors giving each transformation stage a distinct name (as shown here) because Haskell's pervasive laziness makes it easy to lose track of which binding a shadowed name actually refers to at the point it is evaluated.

Rust achieves private helper values with ordinary local let bindings inside a function body. Haskell's where clause attaches helper bindings to the end of a function definition instead of the beginning, and — unlike a Rust local variable — those bindings can be mutually recursive with each other and can carry their own type signatures.

Rust distinguishes compile-time const declarations from ordinary variables with a dedicated keyword. Haskell has no separate constant syntax — a top-level binding with no arguments, like maxRetries, is already a compile-time-known, permanently immutable value, so it plays the same role without any special keyword.

Both languages catch type errors at compile time rather than at runtime, which is a large part of what makes each language "feel safe" compared to a dynamically typed one. The type inference engines differ in strength, though: Haskell's Hindley–Milner-based inference can infer the types of entire function definitions with no annotations at all, while Rust's local type inference generally still needs an explicit function signature.

Rust's function signature groups all parameters in one parenthesized list followed by -> ReturnType. Haskell writes a signature as a chain of types joined by ->, with no visual grouping of the parameters at all — Int -> Int -> Int literally reads "takes an Int, then takes another Int, and produces an Int." This is not cosmetic: it reflects the fact that Haskell functions are curried (see the Higher-Order Functions section), whereas Rust functions are not.

Rust generics are written <T: Bound> before the parameter list. Haskell writes the equivalent constraint before the signature with a fat arrow: Ord a => [a] -> a means "for any type a that implements Ord." The underlying idea — a function that works uniformly over any type satisfying a constraint — is the same in both languages; only the surface syntax differs.

Notice double = (* 2) has no explicit parameter at all — this is "point-free" style, and it type-checks because Haskell's inference engine can determine that double must be a function from the way it is later applied to a list of Int via map. Point-free definitions like this are idiomatic in Haskell; Rust's type system does not support omitting the parameter list in this way.

This is one of the closest one-to-one mappings between the languages: Rust's Some(x)/None correspond exactly to Haskell's Just x/Nothing, and both types exist for the same reason — making the absence of a value part of the type system so the compiler forces you to handle it. A Rust programmer who already avoids null in favor of Option will find Maybe immediately familiar.

Rust's Ok(value)/Err(error) correspond to Haskell's Right value/Left error — note the reversed order in the name Either e a (error type first, success type second), which trips up many newcomers. The mnemonic "right is right" (correct) helps: Right always holds the success case, matching Rust's Ok.

Rust's option.unwrap_or(default) and Haskell's fromMaybe default maybeValue do exactly the same job — unwrap the value if present, otherwise substitute a default — just with the argument order reversed and the receiver/argument relationship flipped, since Haskell has no method-call syntax.

Rust's Option::map and Haskell's fmap (or the Functor operator <$>) both apply a function to the contained value only if one is present, otherwise passing the absence through unchanged. The difference is scope: Rust's .map() is a method defined specifically on Option and Result, while Haskell's fmap is one function that works identically across Maybe, lists, Either, IO, and any other type that implements the Functor typeclass.

Rust's Option::and_then chains fallible operations, short-circuiting to None as soon as any step fails — this is exactly what Haskell's bind operator >>= does for Maybe. This is not a coincidence: and_then is Rust's name for what the rest of the functional programming world calls monadic bind, and Haskell's >>= is the same operation spelled out as a first-class operator that works across every monad, not just Maybe.

The structure is almost identical: both use _ as the catch-all wildcard, and both compilers enforce exhaustiveness — the compiler warns (or errors, with the right flags) if a case is missing. The main syntax differences are => versus -> for each arm and the absence of commas separating Haskell's cases.

Rust matches on the parameter's value inside a match expression in the function body. Haskell instead lets you write one equation per pattern, directly at the top level of the function definition — the runtime tries each equation top-to-bottom and uses the first whose pattern matches. There is no equivalent syntax in Rust; the closest analogy is Rust's slice patterns inside a single match, shown here for comparison.

Both languages let you destructure a struct/record or tuple directly in a let binding, pulling fields out into individually named bindings in one step. The syntax is nearly identical — Rust's let Point { x, y } = point; and Haskell's let Point { pointX = x, pointY = y } = point express the same idea, though Haskell requires explicitly renaming each field since it has no shorthand field-punning by default outside of an extension.

Rust attaches a guard condition to a match arm with pattern if condition => .... Haskell's guards live directly in a function definition, introduced by |, with otherwise (which is just True) playing the role of the catch-all — a style that reads almost like a mathematical piecewise definition.

Rust's slice patterns, like [first, second, ..], cover the same ground as Haskell's cons pattern (first:second:_): both split a list into named leading elements plus "everything else." The underlying representations differ, though — a Rust slice is a contiguous, indexable array in memory, while a Haskell list is a chain of cons cells, so the pattern (x:rest) is really peeling one link off that chain rather than indexing into a buffer.

This is the single biggest structural difference between the two languages. Rust's compiler enforces ownership and borrowing rules so that memory is freed deterministically with no garbage collector; Haskell has none of that machinery. Every Haskell value is managed by a tracing garbage collector, so there is no concept of "moving" a value, no lifetimes to annotate, and no possibility of a use-after-move or dangling-reference compile error — those bug categories simply do not exist in Haskell, at the cost of GC pauses and less predictable memory reclamation timing.

Rust needs explicit reference-counted wrapper types like Rc<T> (single-threaded) or Arc<T> (thread-safe) whenever a value must be shared among multiple owners, because its ownership model otherwise only permits one owner at a time. Haskell requires no such wrapper — any value can be bound to as many names as you like, because the garbage collector (not an ownership graph) decides when memory is reclaimed.

Rust's let mut plus &mut references give you compiler-checked, in-place mutation of ordinary variables. Haskell keeps ordinary bindings permanently immutable and instead offers IORef — an explicit, boxed mutable cell that can only be read and written inside IO. Reaching for IORef is the exception in Haskell, not the default, whereas mut is a routine, lightweight choice in Rust.

Rust's explicit lifetime parameter 'a tells the borrow checker that the returned reference must not outlive either input — a piece of ceremony that exists purely to make borrowing safe without a garbage collector. Haskell's equivalent function needs no such annotation at all: strings are ordinary garbage-collected values, so there is nothing for a lifetime to describe.

This is one of the largest behavioral differences a Rust programmer will meet in Haskell. Rust evaluates every expression as soon as it is bound, exactly where it appears in the code, which is why calling expensive() in the left-hand example immediately prints its message. Haskell instead builds an unevaluated "thunk" for expensive and only forces it — actually runs the computation — the first time its value is genuinely needed; here it never is, so the computation never happens at all.

Rust's unbounded Range (1..) is the closest built-in analogue to a Haskell infinite list, and both rely on laziness to stay finite in practice. The difference is how pervasive the laziness is: Rust's Range is a special-cased lazy iterator, while in Haskell every list — including a plain [1..] literal with no special iterator type — is lazy by construction, so infinite lists fall out naturally rather than requiring a dedicated abstraction.

Laziness is usually a benefit, but it has a well-known failure mode: repeatedly deferring computation can build up a long chain of unevaluated thunks that eventually overflows the stack or wastes memory — a problem Rust's eager evaluation never has. Data.List.foldl' (the trailing apostrophe signals "strict") forces each step immediately, sidestepping the thunk build-up; reaching for it over plain foldl in accumulation-heavy code is a well-known Haskell idiom.

Laziness governs pure computation, not the sequencing of side effects. Inside a do block, IO actions are always performed strictly, top to bottom, exactly like Rust's sequential statements — this is an important exception for a Rust programmer to internalize early, since it is easy to over-generalize "Haskell is lazy" into assuming output order is unpredictable, when in fact IO sequencing is completely deterministic.

Rust's enum and Haskell's data both define a sum type — a value that is exactly one of a fixed set of alternatives. The syntax reads almost identically, and both compilers enforce exhaustive matching over the alternatives. deriving (Show) is Haskell's equivalent of Rust's #[derive(Debug)], automatically generating a string representation.

Each Rust enum variant can carry an inline tuple or struct of data, exactly as each Haskell constructor can carry positional fields. Shape::Circle(f64) and Circle Double are the same idea, and both languages let you destructure the payload directly in a pattern-matching arm — Shape::Circle(radius) versus Circle radius.

Rust structs are always product types with named fields, roughly equivalent to Haskell's record syntax, data Person = Person { ... }. One naming quirk: Haskell field accessors live in a single flat namespace shared across the whole module, so real code typically prefixes each field name (personName, personAge) to avoid collisions with a similarly named field on a different record — Rust has no such restriction, since person.name is always scoped to Person.

Both languages support "functional update" — building a new value that copies every field from an existing one except the fields you name explicitly. Rust's ..alice.clone() spread requires an explicit clone because the original alice would otherwise be moved; Haskell's alice { personAge = ... } needs no such clone, since every value is already immutable and freely shareable.

Rust's tuple-struct newtype pattern, struct UserId(u32), and Haskell's dedicated newtype keyword solve the same problem: preventing a raw u32/Int from being passed where a semantically distinct identifier is expected. Haskell's newtype is guaranteed to compile away entirely, adding zero runtime overhead compared to a plain Int — a stronger, compiler-enforced version of the guarantee Rust's equivalent single-field tuple struct also aims for.

This is another very close parallel between the languages. Rust's trait defines an interface; Haskell's class keyword does the same thing (confusingly named — it has nothing to do with object-oriented classes). Rust implements a trait for a type with impl Trait for Type; Haskell implements a typeclass for a type with instance Class Type where. Both compilers require every method of the interface to be provided (unless a default is supplied) and both reject calling a typeclass/trait method on a type that has no instance/impl for it.

Both traits and typeclasses can supply a default implementation for a method, which any implementing type inherits automatically unless it chooses to override it. Rust writes the default directly in the trait body; Haskell does the same directly in the class body — structurally identical, just spelled differently.

Rust constrains a generic parameter with a trait bound, written <T: Display>. Haskell constrains a type variable with a typeclass constraint, written before the signature with a fat arrow: Show a =>. Both mechanisms restrict a polymorphic function to only the types that support the required operations, and both are checked at compile time.

Rust's #[derive(...)] attribute and Haskell's deriving (...) clause both ask the compiler to generate boilerplate typeclass/trait implementations automatically — equality, ordering, string conversion, and so on — rather than writing them by hand. The concept transfers directly; only the placement differs, with Rust's derive attached above the type and Haskell's deriving clause attached after it.

Rust's Box<dyn Trait> lets a single collection hold multiple concrete types that all implement the same trait, dispatched at runtime through a vtable. Plain Haskell has no built-in equivalent — reaching the same result requires the ExistentialQuantification language extension to wrap heterogeneous values in a single existential type like AnyAnimal above. This is meaningfully more ceremony than Rust's dyn, and is one of the few places where idiomatic Rust is actually the more concise option.

Rust closures use pipe syntax, |number| number * 2; Haskell lambdas use a backslash (evoking the Greek letter λ) followed by ->, \\number -> number * 2. Both create anonymous functions that can capture bindings from the surrounding scope. The deeper difference, covered next, is that Haskell's multi-argument lambda is secretly a chain of single-argument functions, while Rust's is not.

This is a fundamental difference in how the two languages model multi-parameter functions. A Rust function like fn add(first: i32, second: i32) -> i32 genuinely takes two arguments at once — partial application requires manually writing a wrapping closure. Every Haskell function of "two arguments" is secretly a function of one argument that returns another function of one argument; add 5 is a perfectly ordinary, complete expression that evaluates to a new Int -> Int function, with no closure syntax required.

Both languages treat functions as first-class values that can be passed as arguments. Rust spells the parameter type with impl Fn(i32) -> i32 (or the more general Box<dyn Fn(i32) -> i32> for dynamic dispatch); Haskell spells it simply as (Int -> Int), a function type written the same way as any other type. (* 2) and (+ 10) here are operator sections — partially applied operators — one of the more distinctively terse pieces of Haskell syntax.

Rust's iterator adapters (.filter(), .map(), .sum()) are chained as methods and are lazy until a terminal call like .sum() or .collect() runs them. Haskell's filter, map, and sum are ordinary top-level functions rather than methods, composed by nesting or with . — and because Haskell lists are lazy by construction (see the Laziness section), no explicit terminal call is needed to trigger evaluation; the outer print forces the whole chain.

Rust performs IO with ordinary synchronous function calls, using Result and the ? operator to propagate failures such as a broken stdin stream. Haskell instead requires that any function performing IO carry IO in its type signature, and sequences those IO actions inside a do block using <- to bind results — a difference that is more about making side effects visible in the type system than about any change in what the program actually does. This example is marked non-runnable because it reads from standard input, which the in-browser Compiler Explorer runner cannot supply interactively.

This is a distinction Rust's type system does not make: a Rust function's signature says nothing about whether it prints, mutates a file, or is otherwise "impure" — pure_double and print_and_double have signatures that look equally innocent. In Haskell, any function that performs a side effect must say so by returning something wrapped in IO; a function with no IO in its type, like pureDouble :: Int -> Int, is guaranteed by the compiler to be a pure computation with no observable side effects at all.

In Rust, return is a control-flow keyword that immediately exits the enclosing function with the given value. Haskell reuses the word return for something completely unrelated: it takes an ordinary pure value and wraps it in a monad — most commonly IO — with no effect on control flow whatsoever. A Rust programmer's intuition about return will actively mislead them here; modern Haskell style even prefers the identical function pure over return specifically to avoid this false association.

Rust's for fruit in fruits loop and Haskell's mapM_ putStrLn fruits both perform an IO action once per element, in order, discarding any results. There is no dedicated loop syntax in Haskell for this — mapM_ is an ordinary function, and the trailing underscore is a naming convention (shared with several other Haskell functions) meaning "run this for effect and throw away the results."

Rust's ? operator on Result (and Option) is Rust's closest brush with monadic chaining: it threads a computation forward and short-circuits at the first failure, unwrapping the success case automatically at each step. Haskell's do-notation over Maybe does precisely the same job — each <- line is a bind that short-circuits to Nothing the moment any step fails. Recognizing this parallel is the single most useful bridge for a Rust programmer trying to build intuition for what a "monad" actually is: it is the general pattern that ? only implements for Result/Option specifically.

Rust bakes short-circuiting behavior directly into the language for Result and Option via ?, but there is no general, user-extensible "Monad trait" in the standard library that other types can opt into. Haskell instead defines Monad as an ordinary typeclass — the same mechanism used for Show, Eq, and Ord — with (>>=) and return/pure as its core operations, so Maybe, Either e, lists, IO, and countless user-defined types can all share this one interface and inherit do-notation for free.

This example makes the ?-to-do-notation parallel concrete over three chained steps. Rust's let first = half(start)?;, repeated three times, and Haskell's first <- half start, also repeated three times, both stop at the first failure and propagate its error unchanged — Rust returns from the function early, and Haskell's Either monad short-circuits the rest of the do block to the same Left value.

Rust has no dedicated comprehension syntax — building a transformed list always means chaining iterator adapters like .map() and finishing with .collect(). Haskell's list comprehension, [x * x | x <- [1..5]], reads close to mathematical set-builder notation: the part before | is the output expression, and x <- [1..5] is the generator supplying values of x.

Adding a condition after the comma in a Haskell comprehension — , even x — acts as a guard that filters the generator, combining what Rust would express as a separate .filter() call chained before .map(). A single Haskell comprehension can combine multiple generators and multiple guards in one expression, which often reads more compactly than the equivalent chain of iterator adapters.

Rust expresses a Cartesian product with nested for loops that push into a mutable vector. Haskell expresses the same computation with multiple generators in a single comprehension, first <- [1..3], second <- [1..3], which iterates every combination — no explicit nesting, no mutable accumulator, and no separate loop bodies required.

Rust has no built-in operator for composing two functions into a new one — the idiomatic approach is a closure that manually calls one function on the result of the other, as shown here. Haskell's . operator composes functions directly: negateValue . double builds a brand-new function without ever naming its argument, reading right-to-left just like mathematical function composition notation, f ∘ g.

Rust builds a processing pipeline by chaining methods left-to-right in the order each step happens: split, then reverse, then uppercase. Haskell's .-composed pipeline, map (map toUpper) . reverse . words, reads in the opposite order — rightmost first — because . mirrors mathematical composition. This right-to-left reading is one of the most common early sources of confusion for a Rust programmer new to Haskell, precisely because it inverts the left-to-right method-chain intuition Rust builds.

The $ operator is simply function application with the lowest possible precedence, so f $ g $ x means exactly f (g x) but without the nested parentheses. Rust rarely needs an equivalent because its dot-chained method calls already avoid nested-parenthesis pileups; Haskell's prefix function-call style means $ earns its keep specifically to keep deeply nested calls readable.

Rust uses braces and semicolons to delimit blocks and statements, so indentation is purely a style convention enforced by rustfmt, not the compiler. Haskell's "layout rule" makes indentation itself part of the grammar: every binding inside a do block, where clause, or let group must line up at the same column, and shifting a line's indentation can silently change — or break — what the code parses as. This is a frequent early source of confusing compile errors for newcomers.

This symbol overlap is a classic trap: Rust's :: separates path segments, as in std::cmp::max or Vec::<i32>::new(). Haskell's :: means something entirely different — "has type," used to annotate an expression's type, as in numbers :: [Int]. Haskell's module-qualification instead uses a single dot, Data.List.sort, which is itself easy to confuse with Rust's field-access dot at first glance.

Rust makes mutability opt-in but common — reaching for mut to accumulate a running total in a loop is completely ordinary, idiomatic Rust. Haskell makes immutability the unyielding default for all pure code, with no lightweight equivalent of mut at all; accumulating a value always means transforming an old value into a new one, typically via a fold, recursion, or a comprehension, rather than mutating a variable in place. A Rust programmer's instinct to reach for a mutable accumulator needs to be retrained toward "what fold produces this value" instead.

Because Rust evaluates eagerly, a running total computed in a loop never accumulates unevaluated work — each addition simply happens. Because Haskell evaluates lazily, the naive equivalent (a plain, non-strict foldl) can silently build up a million-deep chain of unevaluated additions instead of a single number, and only try to evaluate all of them at once at the very end — sometimes overflowing the stack. Reaching for the strict foldl' (or otherwise forcing intermediate values) is a necessary habit for a Rust programmer to build when writing accumulation-heavy Haskell code.

Rust requires numeric literals to eventually resolve to a concrete type, and once you have written that type down, there is no further ambiguity to reason about. Haskell's "monomorphism restriction" is a subtler trap: a top-level or let-bound value with no type signature and no arguments can be silently defaulted to a specific type (usually Integer or Double) rather than staying as general as its usage would otherwise allow, which can produce confusing type errors when that binding is later used somewhere expecting a different numeric type. Adding an explicit type signature to top-level bindings, as this codebase does throughout, avoids the surprise entirely.