OCaml.CodeCompared.To/F#

OCaml's let () = … is a pattern binding that both runs the expression and asserts it has type unit. F# keeps the same underlying rule — a top-level expression must be unit — but lets you write the expression on its own, which reads as a statement even though it is not one. printfn is Printf.printf with a newline appended; printf without the n is the exact analogue.

In both languages the literal is not a string but a value of a special format type, and the compiler reads its directives to determine what arguments printf demands. %s, %d, %f and %b mean the same things in both. F# adds %A, which pretty-prints any value structurally — records, unions, lists and all — and is the closest thing to a built-in debugger print. OCaml has no equivalent without a ppx deriver.

The <Compile Include> list is ordered, and the order is significant: F# compiles files strictly top to bottom, and a file may only reference definitions from files above it. There is no equivalent of OCaml's dependency-resolving build, where dune works out the order from the module graph. This forces a linear architecture on every F# project and is the single most surprising constraint for someone arriving from OCaml. On the other hand, dotnet is both package manager and build tool, where OCaml splits the job between opam and dune.

The [<EntryPoint>] attribute marks a function taking a string[] of command-line arguments and returning the process exit code as an int. It is optional — top-level code works, as every other example on this page shows — but it is the only way to receive the arguments without reaching for System.Environment.GetCommandLineArgs, and returning a non-zero code from it is cleaner than calling exit. OCaml has no such declaration: Sys.argv is a global array, and the exit code comes from exit or from falling off the end.

This is the largest syntactic change between the two languages, and it is almost entirely a subtraction. OCaml's let … in is an expression that nests, which is why a sequence of bindings becomes a staircase of ins. F# uses the offside rule instead: a let is in scope for everything indented at or beyond its own column. F# does still accept let … in on one line, and its "verbose syntax" accepts the OCaml spelling wholesale, but neither is idiomatic and nobody writes them.

OCaml's ; is an operator meaning "evaluate the left side for its effect, discard it, then evaluate the right side," and it is required. F# treats a newline at the same column as exactly that, so the semicolons vanish. The trap for an OCaml programmer is the opposite direction: a stray ; at the end of an F# line is legal and does nothing, but a stray one in OCaml where you meant ;; — or a missing one — produces type errors about unit that name a line far from the mistake.

The final expression of an F# function body is its return value, exactly as in OCaml. The one name change visible here is List.fold_left becoming List.fold; F# also has List.foldBack for what OCaml calls fold_right, and its standard library uses camelCase for multi-word names throughout (List.tryFind, String.length, Option.defaultValue) where OCaml uses snake_case.

The columns are identical apart from the printing. Both infer add : int -> int -> int and both generalize describe over the element type. The one behavioral difference to know about is that F# infers left to right, top to bottom and cannot use information from later in the file — a consequence of the ordered compilation the project file imposes. OCaml solves constraints across the whole unit, so it happily infers a type from a use that appears after the definition.

OCaml's ref is an ordinary record with one mutable field, so a counter costs an allocation and every read costs a dereference. F#'s let mutable is a genuine mutable location, and <- assigns to it. F# also has ref cells with the same := and .Value spelling, kept for the cases where a ref cell must be captured by a closure or escape its scope — but for a local counter let mutable is both faster and what everyone writes.

OCaml's int is 63 bits on a 64-bit platform, because one bit is spent on the tag the garbage collector reads. F#'s int is System.Int32 — 32 bits, because that is what .NET's int is. So the default integer type gets narrower by half when you cross over, and code that fits comfortably in an OCaml int can overflow an F# one. The 64-bit type is int64, written with an L suffix (42L). Note also that F# spells the shift operators <<< and >>> where OCaml writes lsl and lsr.

OCaml writes mod as a keyword-like infix operator; F# uses %, following .NET. The naming difference is a convention rather than a rule: F# uses camelCase for values and functions and PascalCase for types, modules and namespaces, where OCaml uses snake_case for values and capitalizes modules and constructors. F# will happily accept divide_and_remainder, but every library you call will be camelCase, so mixing the two conventions in one file reads badly.

Inside a function body the two are the same: each let creates a fresh binding that hides the previous one, nothing is mutated, and the type may change on the way through. At the top level of a module they diverge. OCaml is happy — the anchor column above shadows value twice at file scope. F# rejects it with error FS0037: Duplicate definition of value, because a module-level let compiles to a static member of a class and two members cannot share a name. So the OCaml habit of refining a top-level binding step by step has to move inside a function. F# also names the int-to-string conversion just string, where OCaml spells out string_of_int.

OCaml has no operator overloading at all, so + is int -> int -> int and floats need their own family: +., -., *., /. and **. F# resolves * by the types of its operands, so one spelling serves every numeric type. The cost is that F# cannot always infer which overload you meant from context alone — a function written as let double x = x * 2 is inferred as int -> int and will not accept a float, where OCaml's *. would have made the intent explicit. When you want a genuinely numeric-generic function, F# needs inline.

OCaml reserves ^ for string concatenation because + is already taken by integers. F# overloads + for System.String, so ^ is unnecessary — though F# still accepts it, for exactly this reason. The idiomatic F# spelling for anything longer than a couple of pieces is string interpolation, $"Hello, {subject}", which has no OCaml equivalent short of Printf.sprintf.

Both languages let you define an operator from a set of symbol characters, and both derive its precedence and associativity from its first character — so +++ binds like + in either language, with no way to declare otherwise. This is one of the details F# copied exactly rather than adapting. The practical difference is cultural: OCaml code defines operators freely (|>, @@, let*), while F# convention discourages inventing new ones outside a library's core vocabulary.

An OCaml string is an immutable sequence of bytes with no declared encoding, so this word occupies six of them and String.length answers 6. An F# string is System.String, a sequence of UTF-16 code units, so the same word is five units and .Length answers 5. Neither is a count of characters in the general case — an emoji is two UTF-16 units and four UTF-8 bytes — but F#'s number is at least close for European text where OCaml's is not. Indexing looks identical and means something different in each: a byte in OCaml, a code unit in F#.

F#'s $"…" embeds any expression in braces and calls ToString() on the result. A typed variant exists too — $"%s{name} is %d{age}" — which reintroduces the compile-time checking of a format string while keeping the values inline, and is the best of both. OCaml's only comparable option is a ppx extension such as ppx_string, which is a build-system change rather than a language feature.

line.Split(',') is a method call on System.String, inherited from .NET, returning a string[]. String.concat is an F# module function, matching OCaml's. Every F# program mixes the two vocabularies, and knowing which is which saves a lot of searching: the F# modules (List, Array, Seq, String, Option) are curried, take the data last and compose with |>; the .NET methods are uncurried, are called with dot notation and do not. When both offer the same operation, prefer the F# module function for pipelines.

elif is F#'s contraction of else if, and it exists because the offside rule makes a chain of nested else if blocks drift rightward. Both languages apply the same rule about a missing else: the if must then have type unit, because there is no value to produce when the condition is false. OCaml reports that as a type error mentioning unit and F# says the branches have different types, but it is the same rule.

OCaml's for … to … do … done becomes F#'s for … in range do, where the range is an ordinary value — 1 .. 3 builds a sequence, and the same syntax works over a list, an array or anything enumerable. That makes F#'s for closer to a foreach than to OCaml's counting loop; the counting form for index = 1 to 3 do also exists for compatibility. As in the mutation row, the while counter is a real mutable binding in F# and a heap-allocated ref in OCaml.

OCaml guarantees tail-call elimination as a language property. F# has no such guarantee from the runtime, but the compiler delivers it in the case that matters most: a directly self-recursive tail call is compiled into a loop, so this function never grows the stack. Tail calls to other functions — mutual recursion, or a call through a function value — are emitted with .NET's .tail IL prefix, which the runtime honors at a noticeably higher cost per call and which is not emitted at all in every configuration. So the habit transfers for self-recursion and needs checking for anything mutual. The int64 annotations are the second thing: this total is 5,000,050,000, which does not fit in F#'s 32-bit default int and would silently print 705082704 instead. It fits in an OCaml int without comment. That is the integer-width row biting in real code, and it is worth seeing once.

Both are immutable singly linked lists, both cons with :: in constant time, both spell the literal with semicolons rather than commas — a detail that trips up anyone coming from almost any other language, and one an OCaml programmer never has to think about. The module functions match too: List.map, List.filter, List.length, List.rev. F# adds a range literal, [ 1 .. 10 ], and list comprehensions in the sequence-expression syntax, neither of which OCaml has.

OCaml indexes an array with array.(index) and a string with string.[index] — two different bracket styles for two different types. F# uses .[index] for both, and modern F# also accepts plain array[index]. Both languages leave arrays mutable regardless of how the binding was made, which is why neither column needs a mutable keyword to assign into one. An F# array is a real .NET int[], so it can be handed to any .NET method that wants one.

OCaml's Map is a functor: Map.Make (String) builds a module specialized to string keys, and every operation is called through that module. F#'s Map<'Key, 'Value> is an ordinary generic type whose key constraint (comparison) the compiler checks directly, so there is nothing to instantiate and nothing to name. Note the F# tuple syntax in Map.ofList: a comma builds a tuple, where OCaml would need explicit parentheses. This is the first appearance of the functor gap, which has its own section below.

OCaml's Seq.t is a function returning a node on demand. F#'s seq<'T> is .NET's IEnumerable<'T>, so it interoperates with every .NET collection and every LINQ method. The module functions line up (map, filter, take, fold), and F# adds sequence expressions — seq { for x in 1 .. 5 -> x * x } — which are a computation expression and get their own section. The practical difference is that in F# a seq can be consumed only once, because IEnumerable is stateful once enumerated, where OCaml's Seq is re-runnable.

OCaml's Set.Make (Int) builds a module specialized to integer elements, and every operation goes through it. F#'s Set<'T> is a generic type whose comparison constraint the compiler checks directly. Both are immutable balanced trees with structural sharing, so union is cheap in both and neither copies. F# exposes the operations twice over — as module functions (Set.union, Set.contains) for pipelining and as members (.Count, .Contains) for dot notation — and this row uses one of each to show they are the same thing.

The range 1 .. 10 is a value in F#, usable anywhere a sequence is, and it accepts a step (1 .. 2 .. 10). The comprehension is the same computation-expression machinery as seq { }, just collected into a list by the surrounding brackets, so a for, an if and multiple yields per iteration are all available inside it. OCaml has List.init to build a list of known length and no comprehension syntax at all — a gap that shows up whenever the construction logic is more than one combinator deep.

This is the feature whose absence hurts most when moving to almost any other language, and F# keeps it. add has type int -> int -> int in both columns, and applying it to one argument is ordinary application rather than a special case. The one place F# breaks the rule is when calling a .NET method: text.Split(',') takes a tuple of arguments, not a curried sequence, so .Split cannot be partially applied. That distinction between F# functions and .NET methods is worth internalizing early.

The operator is the same one-line definition in both (let (|>) value function = function value) and works for the same reason: the module functions are curried and take their data last. F# leans on it much harder — a typical F# program is written almost entirely as pipelines, and the standard library is designed for it. F# also has >> and << for function composition, which OCaml leaves to the user to define.

F# does have optional parameters, written ?greeting, but only on members of a class or record — never on a module-level let function. So the OCaml habit of giving a function a defaulted, named parameter has no direct translation, and the F# answers are to define a type with a method, to pass a record of options, or simply to require the argument. The trailing () in the OCaml column is the usual marker that a function with optional arguments has been fully applied; F# needs no such thing because it has nothing to disambiguate.

Marking a function inline lets F# resolve its operators at each call site rather than committing to one type, using what the language calls statically resolved type parameters. The result is a single double that works for int, float, decimal and any type with a suitable +. OCaml has no equivalent short of passing the operations explicitly — which is precisely what a functor does, and is why OCaml reaches for one where F# reaches for inline. The constraint is inferred here; when it needs writing out the syntax is notoriously dense.

The only differences are conventions: F# capitalizes type and field names, and its type annotation uses Name: type where OCaml writes name : type. Both are immutable by default and both support functional update with with. Underneath, an F# record is a sealed .NET class, which is what gives it the structural equality and comparison discussed in the next row — an OCaml record is a heap block with no methods at all.

OCaml's = has type 'a -> 'a -> bool and works by walking the runtime representation, so it compares anything — and raises Invalid_argument at runtime if it meets a function or a cyclic value. F# derives a real structural equality implementation for each record and union at compile time, so = is checked: comparing two functions is a compile error, not a runtime one. The trade is that an F# type can opt out ([<ReferenceEquality>]) or need [<CustomEquality>], whereas in OCaml every type gets the same behavior whether it suits it or not.

This is another feature F# took verbatim. In both languages the mutability is a property of the field, declared once, and applies to every holder of the record. One F#-only consequence: a record containing a mutable field can no longer be used as a key in a Map or Set without care, because its structural hash would change under it — OCaml's Map has the same hazard but reports it as a mysteriously missing key rather than as anything explicit.

Both check exhaustiveness, both report a missing case as a warning or error naming the constructor, and both allow the leading | on the first case. F# also has the function keyword as shorthand for fun x -> match x with, exactly as OCaml does, so the anchor column's spelling would compile in F# too — it is written out here because the explicit match is the more common F# style. F# additionally allows named union fields (Circle of radius: float), which OCaml gained only recently and spells differently.

OCaml suffixes the option-returning variant with _opt (find_opt, nth_opt, assoc_opt); F# prefixes it with try (tryFind, tryItem, tryHead). Both libraries also keep the raising version under the bare name. The combinators correspond too: Option.map is Option.map, Option.value ~default is Option.defaultValue, and Option.bind is Option.bind.

F# kept OCaml's when rather than adopting a different keyword, and the exhaustiveness rules match: a guard does not count toward coverage in either language, so the wildcard is required in both columns. The one addition F# makes is that a pattern may be bound with as in both languages, and F# extends matching further through active patterns — the next section, and the biggest thing this page has to teach.

A polymorphic variant tag 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, which makes open extensible sums possible with no declaration in advance. F# has nothing like it — every case belongs to one declared union. What F# offers instead is not a replacement but a different tool: active patterns let you match flexibly over existing types without declaring anything, which covers some of the same ergonomic ground from the consuming side rather than the producing side.

In OCaml, match can only take apart a value along the lines its type declaration already drew. An active pattern lets you define new lines: (|Even|Odd|) is an ordinary function whose name makes it usable as a pattern, so Even and Odd become matchable cases on a plain int. Crucially the compiler still checks exhaustiveness — deleting the Odd branch produces an incomplete-match warning, because the pattern declares that those two cases are all there are. That combination of a user-defined view with a preserved exhaustiveness guarantee has no OCaml counterpart.

The _| in (|Number|_|) marks the pattern as partial: it returns an option, and a None simply means this case does not apply. The payoff is that parsing, regular-expression matching and type tests all become things you write inside a match rather than before it, so a chain of alternatives reads as one construct. The OCaml column has to bind the parse result first and match on the option, which works but forces a nesting level per test. Note the F# idiom for .NET's out-parameter methods: Int32.TryParse returns a tuple of the boolean and the value.

This is the form that most changes how code reads. A single-case active pattern always succeeds and is used purely as a view: SplitName (first, last) both destructures and names, in the place where an OCaml programmer would have called a helper and then destructured its tuple. Nested inside a larger match, several such views compose into one pattern. There is no OCaml analogue at all — OCaml's patterns are strictly structural, which is simpler to reason about and strictly less expressive.

F# drops the struct … end delimiters in favor of indentation, and that is the whole visible difference here. Underneath, an F# module compiles to a static .NET class and its members to static methods, which is what makes them callable from C#. The consequence is that an F# module is a compile-time namespace and nothing more: it cannot be passed as a value, returned, or stored — none of which is true of an OCaml module, and all of which the next two rows depend on.

An OCaml functor is a function from modules to modules, so parameterizing over "a type plus operations on it" means building and naming a new module. F# has no such construct at any level: the substitutes are generic types with constraints (as here), interfaces passed as values, and inline with statically resolved type parameters. For the common case — one type parameter with a standard constraint — the F# version is dramatically shorter. For the cases functors exist to serve, such as parameterizing a whole data structure over several types and operations at once, or instantiating the same functor twice with different behavior for one type, F# has no good answer and you restructure around it.

OCaml's first-class modules let a module be packed with (module English) and unpacked with (val …), which is the general mechanism — a packed module can carry types as well as values. F#'s answer is the interface, and { new IGreeter with … } is an object expression, an anonymous implementation created inline with no class declaration. It is lighter than OCaml's packing syntax for this case, and strictly less general: an interface can carry members but not an abstract type, so the OCaml signature's type t has no counterpart here.

Types you declare in F# — records, unions, tuples — cannot be null, and the compiler rejects the literal. But every type that comes from .NET can be, and System.String is one of them, so a string returned by any library method may be null with nothing in its type to warn you. The habit to build is to convert at the boundary: Option.ofObj turns a possibly-null reference into an option the moment it enters your code, after which the rest of the program can be written the way you would write OCaml. Match on null only at that boundary, as this row does.

OCaml's objects are structurally typed and genuinely interesting, and they are also almost absent from real OCaml code — records and modules cover the ground. F# classes are ordinary .NET classes with nominal typing, inheritance and interfaces, and they are unavoidable: every library you call is built from them, and any F# code meant to be consumed from C# has to expose them. The syntax above is a primary constructor with the parameters in the type name, which has no OCaml analogue. For code that only F# will call, records and unions remain the idiomatic choice.

This is the practical upside of the .NET foundation. OCaml's standard library is deliberately small — no HTTP client, no JSON, no date handling beyond Unix, so almost anything needs an opam package. F# inherits everything .NET has, so networking, cryptography, dates, culture-aware formatting and regular expressions are all present without a dependency. The style clash is real: those APIs are object-oriented and uncurried, so they do not pipeline, and idiomatic F# tends to wrap the ones it uses often in small curried functions.

C# will silently widen an int to a double; F# will not, and neither will OCaml. What changes is the naming: OCaml spells out both ends (float_of_int, int_of_float, string_of_int) while F# names only the destination (float, int, string), overloading each across every sensible source type. F#'s int truncates toward zero exactly as OCaml's int_of_float does. The one asymmetry worth remembering is that F#'s string works on any type by calling ToString(), so it will happily produce something unhelpful rather than failing to compile.

F# kept OCaml's exception declaration and its raise, and try … with pattern-matches the exception exactly as OCaml does. Two additions come from .NET: try … finally, which OCaml lacks entirely (its equivalent is the Fun.protect function), and the fact that an F# exception is a real System.Exception subclass, so it can be caught by C# callers and carries a stack trace. Both languages treat exceptions as ordinary and idiomatic, unlike Rust or Go.

OCaml spells the type ('a, 'b) result and F# spells it Result<'T, 'Error>, but Ok and Error are identical. Neither language has Rust's ? operator, so chaining means Result.bind or a custom binding operator in OCaml, and Result.bind or a result computation expression in F# — the latter being much the more pleasant, and the subject of the next section.

OCaml's binding operators let you define let*, and* and let+ as ordinary infix definitions, which flattens monadic code neatly and is entirely sufficient for Option and Result. F#'s computation expression is a whole protocol: a builder type may define Bind, Return, ReturnFrom, For, While, TryWith, Use and more, so the block can contain loops, exception handling and resource cleanup that all thread through the same effect. That is why seq, async, task and query are all the same feature. The cost is visible above: the builder must be written before anything can use it.

The two columns produce the same numbers by completely different routes. OCaml composes combinators, which is concise for simple pipelines and turns awkward once conditionals and nested loops are involved. The F# version reads as ordinary imperative code — a for, an if, a yield — and produces a lazy sequence, because seq is a builder whose For and Yield members thread everything together. Nested loops and multiple yields per iteration stay readable in the F# form and become genuinely hard in the OCaml one.

F#'s async is not a keyword but a computation expression built on the same protocol as seq, which is why let!, for and try all work inside it. It composes: Async.Parallel takes a list of them and runs them together. OCaml 5 instead exposes Domain for parallelism and effect handlers for concurrency, and leaves the scheduler to libraries such as Eio. The consequence an OCaml programmer will feel is that F# has "colored" functions — an Async<'T> is a different type that must be run — while OCaml 5's effects deliberately avoid that, letting ordinary-looking code suspend.

Each OCaml Domain.spawn creates an operating-system thread with its own minor heap — they are expensive, and the guidance is to create about as many as you have cores. Each F# async is a value describing work, and Async.Parallel hands them to the .NET thread pool, so creating thousands is ordinary. That difference decides how you structure a program: OCaml pairs a small number of domains with a library-level scheduler for the fine-grained concurrency, while F# lets the runtime's pool handle it.

Both columns do the same arithmetic and print the same number, and only one of them checked it. A measure annotation makes 100.0<m> a different type from 9.58<s>, and dividing them produces float<m/s> — the compiler does the algebra on the units, so adding meters to seconds is a type error and assigning a speed to a distance is too. All of it is erased at compile time, so this is ordinary float arithmetic at runtime with no cost at all. OCaml's nearest approach is an abstract type per unit hidden behind a module signature, which does stop you mixing meters with seconds — but it cannot express a derived unit, so the quotient above has nowhere to live and you are back to bare floats exactly where the checking would have mattered most. Units of measure are the clearest case of F# saying something in the type system that OCaml's type system, for all its power, cannot.