OCaml.CodeCompared.To/Rust

The OCaml idiom let () = … is a pattern binding, not a function definition — it says "the expression on the right has type unit, and here is the proof." Rust instead requires a function literally named main, and everything at the top level of a file is a declaration rather than something that executes. The trailing ! on println! marks a macro; that is what lets Rust check the format string against its arguments at compile time, in the same spirit as OCaml's typed Printf format strings.

OCaml's "%s appeared in %d" is not a string: it is a value of the built-in format type, and the compiler reads the directives to work out that printf here demands exactly a string then an int. Rust gets there through macro expansion instead — println! parses the literal at compile time and generates code for the specific arguments given. The practical difference is that OCaml's directives name the type (%s, %d, %f) while Rust's {} is type-agnostic and dispatches on the Display trait, so one placeholder serves every printable type.

OCaml separates package management (opam, which installs libraries into a switch) from the build system (dune, which compiles what is installed). Cargo is both at once: Cargo.toml declares dependencies and Cargo fetches, version-resolves, builds and runs them. The practical consequence for a newcomer is that a Rust project is reproducible from its Cargo.toml and Cargo.lock alone, whereas an OCaml project also depends on which switch you have activated.

The similarity is not a coincidence — Rust took let, immutability-by-default and type inference directly from the ML family. The difference to keep in mind is scoping: OCaml's let … in is an expression that introduces a binding over the body that follows it, so it nests, while Rust's let is a statement that runs to the end of the enclosing block. That is why the OCaml column threads in between the bindings and the Rust column simply ends each line with a semicolon.

Both columns rebind value three times and change its type on the last step, from an integer to a string. Neither language is mutating anything: each let creates a fresh binding that hides the previous one, and the old value is still there underneath if an inner scope ends. This is one of the few places where a Rust habit transfers to OCaml unchanged, and it is worth noticing because most languages that borrowed let from ML did not also borrow this.

OCaml runs Hindley–Milner inference over the whole program, so a function's type is discovered and writing it down is optional documentation. Rust infers only inside a function body; signatures are always explicit. This is a design decision rather than a limitation — it means an error is reported at the function that is actually wrong instead of somewhere far away that happened to unify badly, and it means a function's public contract cannot change silently when its body is edited. The cost is exactly what the two columns show: Rust makes you type more.

OCaml tags every value so the garbage collector can tell a pointer from an integer, which costs one bit — hence max_int being 4611686018427387903 rather than the 9223372036854775807 a full 64-bit integer would give. Rust has no runtime tagging because it has no tracing collector, so i64 really is 64 bits. The other half of the difference is behavioral: OCaml wraps silently, while Rust panics on overflow in a debug build and wraps in a release build, so the arithmetic here has to say wrapping_add to state which it wants. When a Rust integer type is not annotated it defaults to i32, which is narrower than an OCaml int and catches people out.

The syntax matches so closely that the columns are nearly identical, and that is the point — this is transferable knowledge. The difference is in representation: an OCaml tuple is a heap-allocated block that the garbage collector manages, so passing one around copies a pointer. A Rust tuple is a value laid out inline, so returning (i32, i32) here moves eight bytes and touches no heap at all. Both languages also have a unit type written (), meaning "no useful value," which is the same idea in both.

The lengths agree here because every character is ASCII. They will not always agree: String.length in OCaml counts bytes — an OCaml string is an immutable byte sequence with no declared encoding — and Rust's len() also counts bytes, but a Rust String is guaranteed to hold valid UTF-8, which OCaml never promises. So the two agree on the number and disagree on what it means: in Rust it is a byte count of known-good UTF-8, and in OCaml it is a byte count of whatever you put there.

OCaml has exactly one string type because the garbage collector makes the question of ownership irrelevant. Rust splits it in two: String owns a heap buffer it will free, and &str is a borrowed window onto somebody else's bytes — a literal baked into the binary, or part of a String. The rule that makes this bearable in practice is the one the example follows: take &str, return String. A parameter typed &str accepts every kind of string without forcing the caller to give anything up, and returning String hands back something the caller owns outright.

OCaml's char is a single byte, so String.iter walks the six bytes and the accented letter comes apart into two pieces of mojibake. Rust's char is a Unicode scalar value — four bytes wide — and .chars() decodes the UTF-8 as it goes, so the accented letter arrives whole. This is the practical payoff of Rust having made UTF-8 a type-level guarantee: the standard iterator can decode because the bytes are known to be decodable. In OCaml, correct Unicode handling means reaching for a library such as Uutf.

String.split_on_char builds the whole list of freshly allocated strings immediately. Rust's split returns a lazy iterator of &str slices that point into the original text and allocate nothing, which is why collect() is needed to force it into a Vec. Leaving the collect off and iterating directly is the cheaper idiom, and it is the habit worth forming: in Rust, splitting a string is normally free.

OCaml's list is a singly linked list, so consing onto the front with :: is constant time and List.length walks the whole thing. Rust's Vec is a contiguous growable array, so pushing onto the back is amortized constant time, len() is free, and there is no cheap way to prepend. The habit to unlearn is building a result by consing and reversing at the end; in Rust you push onto the back and it is already in order. The nearest equivalent to an OCaml list is VecDeque, but it is rarely what you actually want.

An OCaml array is always mutable — there is no immutable array type, and scores.(1) <- 99 needs no permission from the binding. Rust puts that permission in the binding instead: dropping mut from let mut scores makes the assignment a compile error. Both index from zero and both bounds-check at runtime, panicking or raising on an out-of-range index rather than reading past the end.

Note that the OCaml column uses Hashtbl.replace rather than Hashtbl.add. add pushes a new binding that shadows the old one without removing it, so adding the same key twice leaves two entries and Hashtbl.length reports two — the table is really a multimap with a stack per key. Rust's insert has no such mode: it overwrites and hands back the previous value as an Option. The lookup halves line up neatly, with find_opt and get both returning an option that the match must handle.

This is the sharpest illustration of what the garbage collector was buying. OCaml's Map.add is cheap because the old and new maps share their unchanged subtrees, and nothing has to decide when that shared structure dies — the collector does. Rust's BTreeMap is a mutable structure, so keeping the old version means copying it, which is what clone() does and why it is written out rather than implied. Persistent collections do exist in Rust as libraries (im, rpds), and they work by reference-counting the shared nodes, which is the manual version of what OCaml gets for free. The first line of the OCaml column, Map.Make (String), is also a functor application — see the modules section.

This transfers directly. Both languages also apply the same rule about a missing else: an if with no else must have type unit, because there is no value to produce when the condition is false. OCaml states this as a type error mentioning unit; Rust says the branches have incompatible types and names (). The one syntactic thing to remember is that Rust's braces are mandatory and its parentheses around the condition are not, which is the exact opposite of C and catches people who arrive by way of it.

The ref in the OCaml column is the tell. OCaml has no mutable local bindings, so a counter has to live in a heap cell that := writes and ! reads. Rust simply marks the binding mut and the counter stays in a register. This is why while loops are ordinary in Rust and slightly exotic in OCaml, and why an OCaml programmer writing Rust often reaches for recursion where a loop reads better. Rust's 1..=3 is an inclusive range, matching for … to …; the more common 1..3 excludes its upper bound.

Rust does not guarantee tail-call elimination. The optimizer often performs it in a release build, but the language makes no promise, so the same recursive function that is perfectly safe in OCaml can overflow the stack in Rust — and in a debug build, at this depth, it very likely will. This is the single most important habit to change: where an OCaml programmer reaches for a tail-recursive helper with an accumulator, a Rust programmer writes a loop, and it is not considered a step down. The mut on the parameters is how Rust says the accumulator may be updated in place.

In OCaml, add 10 is not a special case — add genuinely has type int -> int -> int, which is int -> (int -> int), so applying it to one argument is ordinary application. Rust has no currying at all: a function with two parameters must be given two. Getting partial application means explicitly returning a closure, and move is required so the closure takes ownership of first rather than borrowing a local that is about to disappear. The consequence for everyday code is that OCaml's point-free pipelines do not survive translation, and Rust reads more explicitly as a result.

OCaml has one function type, written with arrows, and every function inhabits it. Rust has three closure traits, distinguished by what the closure does to its captures: Fn may be called repeatedly and only reads them, FnMut may be called repeatedly and mutates them, and FnOnce consumes them and can therefore be called only once. Writing F: Fn(i32) -> i32 asks for the most permissive one the caller can supply. That taxonomy exists purely because Rust tracks ownership; with a garbage collector the distinction has nothing to track and OCaml does not need it.

The trailing () in the OCaml column is not decoration: a function whose last parameter is optional cannot be known to be fully applied, so an ordinary unit argument is added to mark the end. Rust's absence of named arguments is a long-standing and deliberate gap, and the community answer is the builder pattern or an options struct, as here. ..Default::default() fills in every field not written out. The practical effect is that Rust APIs tend to expose several small functions where an OCaml API would expose one function with optional arguments.

|> is just an infix operator meaning "apply the function on the right to the value on the left," and it reads well only because List.filter predicate is already a partially applied function waiting for its list. Rust cannot define |> usefully for exactly the reason the currying row gave, so it chains methods instead — each adaptor returns a new iterator, and nothing is computed until sum() asks for a result. The OCaml column, by contrast, builds a full intermediate list at every step.

The correspondence is real and the syntax is nearly interchangeable. The #[derive(Clone, Copy)] line has no OCaml equivalent because it answers a question OCaml never asks: whether using origin after building shifted from it should be allowed. Copy says this type is cheap enough to duplicate implicitly, so origin survives. Without it, ..origin would move the value and the first println! would fail to compile. Every OCaml record behaves like the Copy case from the programmer's point of view, because the collector makes aliasing free.

In OCaml a mutable field is mutable for everybody who can reach the record, forever — there is no such thing as a read-only view of it. Rust puts the permission on the binding and on the reference, so the same Counter can be handed out as &Counter (nobody may write) or &mut Counter (exactly one holder may write). That is why Rust needs no mutable keyword on the field: the answer is decided at each use site rather than once at the type definition.

The OCaml arrangement is a module convention rather than a language feature — area is just a function whose first parameter happens to be a rectangle, and calling it is area small. Rust's impl block gives the same functions a receiver, so the call becomes small.area() and method resolution can find it from the type. Note also that OCaml uses distinct operators for floating-point arithmetic — *. rather than * — because it has no operator overloading, while Rust overloads * through the Mul trait.

Both are true algebraic data types, both check exhaustiveness at compile time, and deleting a branch from either column produces a compile error naming the case that is now unhandled. The differences are cosmetic: Rust qualifies each constructor with its type (Shape::Circle), and OCaml's function keyword is shorthand for a one-argument fun that immediately matches. What an OCaml programmer should take away is that match here is not a switch statement that happens to look similar — it is the same construct, with the same guarantee.

Option is one of the clearest places Rust took an ML idea unchanged, down to the constructor names Some and None. The combinators line up too: OCaml's Option.map, Option.value ~default and Option.bind are Rust's map, unwrap_or and and_then. One representational bonus Rust has: Option<&T> is the same size as a bare pointer, because the null pointer is used to represent None — the optimization OCaml cannot make because it must distinguish None from a pointer at runtime for the collector.

The only real difference is the keyword: OCaml writes when and Rust writes if. Everything else lines up, including the important semantic detail that a guard does not count toward exhaustiveness in either language — the compiler cannot prove n < 0 and n > 100 cover the rest, so the wildcard is required in both columns. Rust's &'static str return type is a lifetime annotation saying the returned string lives for the whole program, which is true of string literals; the lifetimes section returns to this.

Every OCaml value of a variant type is already a pointer to a heap block, so a type may mention itself freely — the size is always one word. Rust lays values out inline by default, so a Node containing two Trees directly would have infinite size, and the compiler says exactly that. Box<Tree> is a heap pointer with a known size, which breaks the cycle. This is the same allocation OCaml was doing all along; Rust simply makes you write it down, and in exchange the non-recursive parts of your data stay unboxed and cache-friendly.

The visible differences are conventions rather than semantics: Rust module names are lower case and members are private until marked pub, while OCaml module names are capitalized and members are public unless a signature hides them. The deep difference is what a module is. An OCaml module is a value-like thing that can be passed to a functor, returned, and stored; a Rust module is purely a namespace, resolved at compile time and unable to be abstracted over. Everything OCaml does with functors, Rust does with traits and generics instead.

The OCaml column names a module, IntDescription, and the caller must know that name to use it — the association between int and its description is carried by the module, not by the type. Rust attaches the implementation to i32 itself, so 42.describe() works with nothing named at the call site, and any generic function bounded by Describable will find it automatically. That automatic resolution is the thing OCaml genuinely lacks and the reason traits feel lighter in daily use. What OCaml gains in exchange is the subject of the next two rows.

A functor is a function from modules to modules, so parameterizing means building a new module, naming it, and calling through it. Rust puts the constraint on a type parameter (T: PartialOrd) and the compiler finds the implementation, so there is nothing to name and nothing to instantiate. Both are resolved at compile time and both monomorphize, so neither pays at runtime. The trade is expressiveness against ceremony: a functor can take several types and several operations at once and can be applied more than once to the same type with different behavior, which trait resolution deliberately forbids — see the next row.

Coherence is what makes 42.describe() unambiguous in the earlier row — there is only one candidate, so the compiler never has to ask which. The price is that i32 cannot have two different Ord implementations, and OCaml's "apply the functor twice with different orderings" has no direct translation. The two Rust workarounds are both on display in spirit: pass the comparator as a value, as here, or define a wrapper type (struct Descending(i32)) whose sole purpose is to carry the second implementation. An OCaml programmer should expect to reach for one of these regularly.

OCaml's first-class modules let a module be packed into a value with (module English) and unpacked with (val …); Rust's dyn Greeter is a trait object, a fat pointer carrying the data and a vtable. The parallel is exact, including the cost: both give up the compile-time specialization that functors and generic bounds provide. The keyword dyn is mandatory in modern Rust precisely so that the choice to dispatch dynamically is visible in the source, which is the same motivation behind OCaml making you write the packing and unpacking out.

In OCaml, let second = first copies a pointer and both names refer to the same list forever; nobody frees anything until the collector proves nobody can reach it. Rust has no collector, so it needs a rule that says who is responsible for freeing: assignment moves ownership, and the original binding becomes unusable. Writing let second = first; here and then using first gives "borrow of moved value", which is the error every newcomer meets first. The & in the example asks for a borrow — a temporary reference that does not take ownership — which is what an OCaml programmer means nearly every time they write an assignment like this.

If describe took Vec<i32> by value, the first call would consume numbers and the second would not compile. Taking &[i32] instead borrows, so the caller keeps ownership and can call as many times as it likes — which is exactly OCaml's behavior. The general rule that makes Rust feel less alien is: take a reference unless you need to keep the value. Note also that the parameter is &[i32] rather than &Vec<i32>; a slice accepts vectors, arrays and sub-ranges alike, so it is the more useful signature.

This is the compensation for the previous rows: because OCaml's default data structures are immutable, sharing and copying are indistinguishable and the language can share aggressively without anyone noticing. Rust's collections are mutable, so it must know whether you wanted the same buffer or a new one, and clone() is how you say "a new one." An OCaml programmer's instinct that copying is expensive and to be avoided is correct here — but so is the instinct that a clone in an inner loop is a design smell rather than a fix.

Rc is "reference counted": each Rc::clone bumps a counter rather than copying the data, and the value is freed when the count reaches zero. That is exactly what OCaml's collector does for every value, which is why the OCaml column needs no special type at all. Two things to carry across: Rc::clone is cheap and is written as a clone only to make the count bump visible; and Rc cannot free a cycle, so a cyclic data structure — trivial in OCaml — leaks unless one direction uses Weak. For sharing across threads the equivalent is Arc.

ref x allocates { contents = x } on the heap, ! reads the field and := writes it. That is genuinely all it is. Rust needs no such indirection because mut is a property of the binding, so total stays a stack slot and the loop compiles to an add. When a Rust programmer does need heap indirection with shared mutability they reach for Cell or RefCell, which are the true analogues of OCaml's ref — see the next row.

This is the closest Rust type to an OCaml ref, and the comparison is instructive. Both let any holder write. The difference is that RefCell still enforces "one writer at a time" — it just does so at runtime, by panicking if you call borrow_mut() while another borrow is live. So the bug that OCaml would let you write (two parts of a program mutating the same cell in an interleaved way and confusing each other) is not prevented in Rust either, but it does become a loud panic instead of quiet corruption. The thread-safe version is Mutex.

Both columns print the same two lines, and the single difference between them is the pair of braces. In OCaml the alias is live across the mutation and reads 99 through it afterwards — perfectly legal, and entirely unchecked. Rust rejects exactly that: keeping alias alive past the assignment is "cannot borrow numbers as mutable because it is also borrowed as immutable," so the borrow has to be confined to a block that ends first, and the last line must read numbers because alias no longer exists. This rule is what makes data races impossible in safe Rust, and it is also the source of most fights with the compiler in the first month. The mental shift is that Rust is not asking "is this correct?" but "can I prove this is correct?", and it declines what it cannot prove even when a human can see the code is fine.

A lifetime is not a runtime thing and it does not change what the code does; it is a compile-time claim relating the validity of the output to that of the input. Here 'a says the returned slice cannot outlive the string it points into, so the compiler will reject any caller that drops the sentence and keeps the word. Note also that the OCaml version allocates — String.sub copies the characters out — while the Rust version returns a view into the original with no allocation at all. That is the payoff the annotations buy.

Rust applies three elision rules that cover the overwhelming majority of signatures. The one at work here is the second: if there is exactly one input reference, every output reference is assumed to borrow from it. The third rule covers methods — an output reference is assumed to borrow from &self. Explicit lifetimes appear only when there are several input references and the compiler cannot guess which one the output comes from. In practice an OCaml programmer will write far fewer of these than the syntax's reputation suggests.

In OCaml the local string is heap-allocated and survives because the caller holds it. In Rust a String built inside the function is dropped when the function returns, so a reference to it would dangle — and the compiler refuses, naming the local that does not live long enough. The fix is almost always the one shown: return the owned String rather than a borrow of it. This pairs with the earlier string rule to give a reliable default for writing Rust functions: borrow the inputs, own the output.

The cultural difference is larger than the technical one. OCaml exceptions are cheap, are not tracked by the type system, and are entirely idiomatic for ordinary control flow — Not_found from a standard-library lookup is normal. Rust's panic! is its nearest equivalent but is reserved for programmer error, and is often configured to abort the process rather than unwind, so it is not something to build on. The rule of thumb when translating: an OCaml exception that a caller is expected to catch becomes a Result, and one that signals a broken invariant becomes a panic!. OCaml's | exception pattern in a match, shown above, is a nice piece of syntax with no Rust analogue.

The two sum_two functions do the same thing, and the difference in weight is the whole story. ? means "unwrap the Ok, or return the Err from this function immediately," collapsing the nested matching in the OCaml column to a single character. OCaml's answer to the same problem is a let* binding operator (let ( let* ) = Result.bind), which gets close but must be defined or imported first and does not compose across different error types the way ? does through the From trait. This is one of the few places where Rust is meaningfully more ergonomic than OCaml.

OCaml's Option.map is Rust's map, Option.value ~default is unwrap_or, Option.bind is and_then, and Option.is_some is is_some. Rust writes them as methods, which chains more comfortably than OCaml's prefix application — parsed.map(…).unwrap_or(0) reads left to right where the OCaml needs either nesting or |>. There is one trap worth naming: Rust's unwrap(), without the _or, panics on None and is the direct equivalent of Option.get. Both are fine in a quick script and a liability in a library.

Each List.filter and List.map in the OCaml column allocates a whole new list, so this pipeline builds two intermediate lists that are immediately discarded. Rust's adaptors are lazy: filter and map return iterator structs that do no work, and only collect() drives the chain, so the whole pipeline runs in one pass with one allocation. OCaml's equivalent is the Seq module, which is lazy in the same way and is worth reaching for on long pipelines — but List is what most OCaml code uses, and the strictness is a real difference in behavior, not just performance.

Both languages can express all three with a fold, and both provide shortcuts. The interesting difference is max: Rust returns Option<&i32> because an empty iterator has no maximum, so the None case is forced into the open — hence the unwrap(). The OCaml column has to invent a starting value, min_int, and would silently return it for an empty list. That is a small but genuine example of Rust pushing an edge case into the type where OCaml lets you paper over it.

OCaml's Seq.t is a function returning a node when called, so nothing is computed until something demands it — the same design as Rust's Iterator trait with its single next method. The mapping between the two module interfaces is nearly one to one: Seq.map/map, Seq.filter/filter, Seq.take/take, Seq.fold_left/fold. The practical difference is that laziness is the default in Rust and the opt-in in OCaml, so a Rust programmer writes long chains without thinking about intermediate allocations and an OCaml programmer has to choose Seq deliberately.

Both spawn, both return a handle, both join to collect the result. The difference is what happens when the closure touches shared data. Rust's join() returns a Result because a panicking thread must be reported rather than silently lost, hence the unwrap(). More importantly, Rust will refuse at compile time to move a non-Send value into the thread — see the next row — while OCaml will happily let two domains share a mutable structure and race on it. OCaml's runtime guarantees no memory unsafety from such a race, but the logical bug is entirely yours.

In OCaml the mutex and the data are separate things, and the connection between them lives only in the programmer's head — delete the Mutex.lock lines and the program still compiles, still runs, and quietly loses increments. In Rust the integer is inside the Mutex, so lock() is the only way to reach it and forgetting is not expressible. Arc is the thread-safe reference count that lets both threads own the mutex. This is the clearest demonstration of what the type system buys: not a faster program, but one where the unsafe version cannot be written by accident.

The Rust channel closes itself: when the sender is moved into the thread and that thread ends, the sender is dropped and the for loop over the receiver terminates on its own. That is ownership doing scheduling work — the type system knows nobody can send again, so the loop can end. The OCaml column has to join first and then drain, because a hand-rolled queue has no way to signal that it is finished. OCaml 5's standard library gives you domains and mutexes and stops there; the higher-level pieces (task pools, channels, parallel iteration) come from Domainslib.

An effect handler lets a computation suspend at an arbitrary depth and hand control to a handler that decides whether and how to resume it — which is how OCaml 5 implements lightweight concurrency without colored functions, and why OCaml has no async keyword. Rust cannot express this: it has no delimited continuations, and its async is a compile-time state-machine transformation that does color every function it touches. The workaround shown, passing the capability as a parameter, covers the simple case and none of the interesting ones. If a reader takes one "OCaml has something Rust lacks" away from this page, it should be this.

The OCaml column writes to_string out by hand because the plain compiler has no deriving mechanism — with ppx_deriving in the dune file it would become type color = Red | Green | Blue [@@deriving show, eq], which is exactly Rust's #[derive(…)] in a different spelling. Note that structural equality is already available in OCaml through the polymorphic =, which works on any type by inspecting representations at runtime; Rust has no such thing, so PartialEq must be derived or implemented before == compiles.

The OCaml column solves the problem with an ordinary function, and that is the honest answer most of the time — a language with first-class functions, currying and functors rarely needs syntactic abstraction. Where OCaml does need it, ppx rewriters operate on the parse tree as a separate build step, which is more powerful than macro_rules! and considerably harder to write. Rust's macros also serve a purpose OCaml has no need for: taking a variable number of arguments, which is why println! and vec! are macros rather than functions.

A polymorphic variant tag such as `Circle is not tied to any one type: two unrelated functions can accept overlapping sets of tags, and the inferred type records exactly which tags a value might carry. That makes open, extensible sums possible without declaring a closed enum in advance. Rust has nothing like it — every variant belongs to one enum, declared up front, which is what makes exhaustiveness checking so straightforward. The usual Rust approximation is a trait with several implementing types, which is open in a different way but gives up exhaustiveness in exchange.