Haskell.CodeCompared.To/Rust

Haskell requires a named main :: IO () entry point that the runtime calls once. Rust requires the same shape, fn main() { ... } — both languages agree that a program needs exactly one designated entry point.

Haskell needs do-notation to sequence IO actions, since it desugars to chained monadic binds. Rust is strict, so statements inside main simply execute one after another in the order written — no monad or block syntax required for plain sequencing.

Haskell's print uses the Show typeclass, deriving a textual representation for (almost) any value automatically. Rust's {:?} debug formatter relies on the Debug trait, which standard types implement out of the box — the output Some([1, 2, 3]) needs no extra formatting call, much like Haskell's derived Show.

Haskell's let ... in bindings and Rust's let both bind an immutable name once by default — reassigning a plain Rust let is a compile error, matching Haskell's single-assignment discipline exactly, unlike Rust's separate let mut (next row).

Haskell reaches for IORef and threads it explicitly through IO with newIORef/modifyIORef/readIORef. Rust's mut keyword offers a plain, in-place mutable local variable directly — no wrapper type, no monad required — and Rust's borrow checker (see the Ownership section) further guarantees that no other alias to count can exist while it is being mutated, a guarantee Haskell's IORef does not provide at all.

Rust infers the type of local values the way Haskell does, so everyday code reads almost as unannotated as Haskell. The difference surfaces at function boundaries: Rust parameter types and return types are always explicit, the one place Haskell's inference goes further than Rust's.

Haskell's lowercase type variable a and Rust's angle-bracketed <T> both introduce a generic type parameter, but Rust requires it to be written explicitly and — since Rust has no garbage collector — commonly requires a trait bound like Clone to specify how the generic value may be handled, something Haskell's GC-backed sharing model never needs to think about at all.

Haskell's ++ is the general list-concatenation operator, since a String is really [Char]. Rust's + concatenates an owned String with a borrowed &str, one of the first places a Haskeller runs into Rust's owned-versus-borrowed string distinction, which has no Haskell parallel at all.

In Haskell the usual route is Text.Printf with positional format specifiers. Rust's println! macro supports captured identifiers directly inside { } placeholders (since Rust 1.58), closer to Python f-strings or Ruby's #{}, and needs no import.

Haskell's String is literally a type alias for [Char], so ordinary list functions like length apply directly and count characters. Rust splits strings into two distinct types — the owned, growable String and the borrowed &str — and neither is a character list: .len() counts UTF-8 BYTES, not characters, so counting actual characters requires the explicit .chars().count() shown here, a genuine trap for anyone assuming .len() means what Haskell's length means.

Haskell's bracket literal [1, 2, 3] becomes Rust's vec![1, 2, 3] macro call. Rust's own bracket literal, [1, 2, 3], makes a fixed-size array; a growable Vec comes from the macro. Under the hood the representations differ completely: a Haskell list is a lazy, singly-linked chain of cons cells, while Rust's Vec is contiguous, heap-allocated, and growable, matching most mainstream languages rather than the functional-language linked-list convention.

Both languages call these operations map and filter. Rust routes them through the Iterator trait, requiring .iter() to enter iterator-land and a terminal .collect() to leave it and materialize a concrete Vec again; Haskell's lists are already the collection, so map/filter apply directly with no separate iterator representation to enter or exit.

Haskell's foldl and Rust's .fold take the same pieces — initial accumulator, then a combining function — in the same order, and even reuse the same name, one of the closer standard-library vocabulary matches on the site.

Both languages provide a map as a first-class collection: Haskell's Data.Map (usually imported qualified, ordered by key) and Rust's HashMap (unordered, needing an explicit use). Both a missing-key Map.lookup and Rust's .get return an optional value rather than throwing/panicking on a missing key.

Haskell's Maybe a (Just x/Nothing) and Rust's Option<T> (Some(x)/None) are essentially the same type with renamed constructors — both replace null with an explicit, compiler-enforced "value or absence" type, and both are the idiomatic default in their respective languages, not a niche escape hatch.

Haskell's Either String Int and Rust's Result<i32, String> carry the same two cases, but the type arguments come in opposite orders: Haskell puts the error type first (Left), Rust puts the success type first (Ok). The case names differ too — Left/Right become Err/Ok, trading a positional convention for names that say what they mean.

Both compilers push back on treating a Result/Either as if it were the bare success value: Haskell rejects it as a type error outright, while Rust's #[must_use] attribute on Result emits an "unused Result that must be used" WARNING if it is silently dropped rather than matched or explicitly handled. Matching both branches — or explicitly calling a combinator that forces a decision, like Rust's .unwrap_or or Haskell's either function — is the idiomatic way to satisfy either language.

Haskell's algebraic data types and Rust's enums with associated data are close structural cousins — both declare a closed set of tagged, optionally payload-carrying variants, deconstructed with pattern matching the compiler checks for exhaustiveness. Rust writes the type prefix, Shape::Circle, where Haskell writes the bare constructor Circle — unless the variants are brought into scope with use Shape::*;.

A payload-free Haskell constructor and a payload-free Rust enum variant translate almost mechanically — Haskell needs an explicit deriving (Show) clause to make the type printable; Rust needs the equivalent explicit #[derive(Debug)] attribute, the same opt-in idea spelled as an attribute rather than a keyword clause.

Haskell needs no special marker for a self-referencing data type — every constructor is already heap-allocated behind a pointer by the runtime. A Rust enum is stored inline with a fixed, known size, so a directly self-referencing variant would have unbounded size; the explicit Box<Tree> heap-allocates that field instead, exactly the representation Haskell uses automatically and silently.

Haskell's case ... of and Rust's match { } read as close dialects of the same construct: patterns tried top to bottom, a guard attachable to a pattern (both reuse | for Haskell, if for Rust's match guards), and a wildcard _ catch-all.

Both compilers verify a match covers every case, but Rust is stricter by default: a non-exhaustive match is an unconditional compile error in Rust, where GHC accepts an incomplete case silently by default, warns about it under -Wincomplete-patterns (part of -Wall), and rejects it only with -Werror on top.

Tuple destructuring is essentially identical syntax in both languages — a parenthesized, comma-separated pattern on the left of a binding, matched positionally against the tuple's shape.

Both define a named product type with labeled fields, using near-identical construction and access syntax — Point { x = 3, y = 4 } versus Point { x: 3, y: 4 }. Access differs: Rust writes point.x, while Haskell calls the field's accessor function, x point — or writes point.x under the OverloadedRecordDot extension.

Haskell's point { y = 99 } and Rust's Point { y: 99, ..point } both produce a new value with one field replaced and every other field copied — nearly identical syntax, with the spread ..point in Rust needing to come last. One real difference: ..point MOVES each remaining field that is not Copy — a String, say — out of point, which is then partly moved and can no longer be used whole; a .clone() (and a #[derive(Clone)]) is the way to keep it. Both fields here are i32, which is Copy, so this example would keep point usable even without the clone. Haskell, with no move semantics at all, never has to think about it.

Haskell spells a lambda \x -> ... (the backslash evoking the Greek letter lambda). Rust spells the same idea |x| ..., pipe-delimited parameters with no arrow before the body — visually close to Ruby's block-parameter syntax, if a Haskeller has that reference point instead.

In Haskell, add 5 alone is already valid — every function is secretly a chain of one-argument functions. Rust functions take a fixed argument list with no automatic partial application at all; getting the same behavior means writing the currying out explicitly, a closure that captures the first argument and calls the original function — the result behaves identically to Haskell's automatic currying, but the intent must be spelled out by hand.

Haskell's . composes function VALUES directly, point-free, with no reference to the argument at all. The idiomatic Rust way to combine two functions is to write a closure that calls one, then the other, explicitly naming the intermediate value the way an ordinary imperative language would.

This is one of the closest parallels between the two languages on the whole site. Haskell's class keyword defines an interface (confusingly named — it has nothing to do with object-oriented classes); Rust's trait does the same thing. Haskell implements a typeclass for a type with instance Class Type where; Rust implements a trait for a type with impl Trait for Type. Rust rejects an impl that leaves out a method with no default, where GHC only warns about the missing method and fails at run time if it is called; both reject calling a typeclass/trait method on a type with no matching instance/impl.

Both traits and typeclasses can supply a default implementation for a method, inherited automatically by any implementing type that does not override it — structurally identical in both languages, just spelled differently: directly in the trait/class body in both cases.

Haskell's (Show a) => constraint and Rust's T: std::fmt::Debug trait bound both restrict a generic function to types that implement a specific interface — the syntax position differs (Haskell's constraint precedes the signature with =>; Rust's bound is attached directly to the type parameter with :), but the underlying idea, "generic over any type with this capability," is identical.

This is the single biggest structural difference between the two languages, and it runs the opposite direction from every other language on this site: here Rust is the one with the genuinely NEW, foreign concept. 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. Rust's compiler instead enforces ownership and borrowing rules so that memory is freed deterministically with no garbage collector at all — a genuinely different tradeoff, not a strictly better or worse one.

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

This particular example happens not to need an explicit lifetime annotation (Rust's "lifetime elision" rules cover this common shape automatically), but many real Rust functions returning a reference derived from a parameter DO require one, written as &'a syntax tied to a specific parameter's scope. Haskell has no lifetime concept whatsoever, in any function, ever — every value simply lives as long as the garbage collector determines something still needs it.

Haskell's [1..] is an ordinary list that only works because Haskell is lazy, generating each element on demand as take asks for it. Rust's (1..) range is not a list at all — it is a lazy Iterator, a completely separate type from the strict, fully-realized Vec used everywhere else on this page, and .take(5).collect() is what actually materializes a concrete, finite Vec from it.

In Haskell, every binding is lazy unless forced otherwise — expensive is not actually computed until print demands it. Rust is strict by default, matching most mainstream languages: expensive is computed the moment its binding line runs, in program order, with no thunk or deferred computation involved.

Haskell's do-notation is syntactic sugar over the general Monad typeclass — it works identically for IO, Maybe, lists, and any other type with a Monad instance. Rust has no IO monad and no need for one: ordinary strict imperative code already sequences actions without needing any special notation, since there is no IO value to thread through pure code the way Haskell does.

Haskell's do-notation over Maybe short-circuits on the first Nothing via the generic Monad typeclass — each <- line is a bind. Rust's ? operator on Option/Result 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 — the same practical effect, reached through a language-level operator rather than a generalized typeclass abstraction.

This is the sharpest conceptual gap between the two languages. Haskell's Monad is one typeclass; any type that implements >>= gets do-notation for free, and the same block of syntax works for IO today and a custom parser type tomorrow. Rust's ? works through a trait, Try, which the standard library implements for Option, Result, ControlFlow and Poll — but stable Rust does not let you implement Try for a type of your own, so there is no user-extensible route to ?-style short-circuiting the way a Haskell Monad instance provides.

Haskell structurally cannot have a "use after move" bug — every value can be referenced from as many places as the program needs, for as long as it needs, full stop. Rust's ownership model means passing a non-Copy value BY VALUE into a function (rather than borrowing it with &) transfers ownership there permanently; using the original binding afterward is a compile error the Rust compiler calls a "move." This is the single most common category of new compile error a Haskeller will hit learning Rust, with literally no prior category of Haskell error to compare it to.

Rust's Option/Result are meant to eliminate unchecked null/error access, but .unwrap() (and its cousin .expect(message)) is a deliberate, always-available escape hatch that panics immediately if the value is actually absent/an error — functionally identical to Haskell's fromJust, which is exactly as unsafe and exactly as tempting to reach for. Idiomatic style in both languages treats this method/function as a last resort, not a first instinct, and both ecosystems have linters that commonly flag its use in production code.