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, unlike the top-level-script style this site's F#/Roc/ReScript pages use.

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.

Haskell has no native interpolation — the idiomatic route is Text.Printf with positional format specifiers. Rust's println! macro supports captured identifiers directly inside { } placeholders (since Rust 2021), 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, fixed &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 has no dedicated list-literal syntax the way Haskell does. 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 in the same order (success type first) — only the case names differ: Haskell's Left/Right become Rust's Err/Ok, trading positional convention for explicitly meaningful names.

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 requires the type prefix Shape::Circle at the construction site, where Haskell just writes the bare constructor Circle.

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. Rust enums are stack-allocated by default 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's equivalent gap is a configurable warning (elevated to an error only under stricter flags like -Werror).

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 }, and both accessed with the same dot notation, arguably the closest struct-literal syntax match on the whole site.

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: Rust's struct-update syntax MOVES the remaining fields out of point by default, so an explicit .clone() (and a #[derive(Clone)]) is needed here to keep using the original point afterward — a consequence of ownership that Haskell, with no move semantics at all, never has to think about.

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. Rust has no built-in function-composition operator; the idiomatic Rust way to combine two functions is simply 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. Both compilers require every method to be provided (unless a default is supplied) and 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 ? operator is special-cased at the language level for Option and Result specifically — there is no way to define your own type and get ?-style short-circuiting through a general, user-extensible mechanism the way Haskell's Monad instance would provide.

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.