OCaml.CodeCompared.To/Ruby

OCaml's let () = … binds the unit pattern, which runs the expression and asserts it produces nothing. A Ruby file is a sequence of statements executed top to bottom. puts is a private method on Object, so it is available everywhere without qualification, and its parentheses are optional — which is a stylistic choice Ruby makes constantly and which takes an OCaml programmer a while to stop reading as a syntax error.

OCaml's format string is a value of the built-in format type, and the compiler reads its directives to demand exactly a string then an integer — a mismatch is a compile error. Ruby's #{} evaluates any expression and calls to_s on the result, so the arguments cannot be in the wrong order in a way the language notices; swapping them prints different text and nothing complains. In exchange the syntax embeds arbitrary expressions, including method calls and conditionals, which sprintf cannot.

There is no build. Ruby reads the source and executes it, so the feedback loop is as short as it can be and there is no artifact to ship — deployment means the source plus the right interpreter and gems. Bundler and opam solve the same problem, and Bundler pins versions in a lock file by default where opam's locking is opt-in. The consequence an OCaml programmer feels most is that a syntax error in a file nothing has loaded yet is discovered when something loads it, which may be in production.

In OCaml an int is a tagged machine word and + is a primitive; there is nothing to call a method on. In Ruby 3 is an instance of Integer, 3 + 4 is 3.+(4), and even nil is an object — an instance of NilClass with methods of its own. That uniformity is why 5.times, 3.upto(7) and x.nil? read the way they do, and it is why any class including Integer can have methods added to it at run time, which the metaprogramming section returns to.

In OCaml only bool may be a condition, so emptiness is asked for explicitly. Ruby treats only nil and false as falsy — 0, "", [] and {} are all truthy, which is the opposite of Python, JavaScript and PHP and is far less error-prone. The idiom if value therefore means "is this present" and nothing else, which is close to what an OCaml programmer means by matching on an option. Emptiness gets its own predicate, empty?, and the trailing question mark is a naming convention the parser allows rather than syntax.

OCaml checks every expression before the program starts. Ruby resolves a method name by looking it up on the receiver at the call, so a typo in a branch nobody exercised is a NoMethodError waiting for the day that branch runs. There is no compiler to ask, and the language deliberately provides no way to declare the answer in advance — Sorbet and RBS exist as external type checkers, and neither is part of the language or widely required. Test coverage takes over the job the type checker was doing, which is why Ruby's testing culture is as strong as it is.

The OCaml variant closes the set: three constructors, proved exhaustive, and a fourth breaks the build until it is handled. The Ruby version is open — any class with an area method joins, from any library, with no coordination — and correspondingly unchecked, since nothing verifies the method exists until the call. Note the endless method definition (def area = …), which Ruby 3 added and which reads very close to OCaml's let area = …; and @radius, an instance variable that springs into existence on first assignment.

OCaml's let introduces a fresh binding over a new scope, so the earlier count still exists and any closure that captured it still sees 10. Ruby's = assigns to the variable in the enclosing scope, so nothing sees the old value afterwards. Ruby's scoping is otherwise stricter than most dynamic languages: a method body cannot see local variables from outside it — only from the block or method it is defined in — which prevents a whole class of accidental capture that Python and JavaScript allow.

An OCaml int is 63 bits and wraps silently, so a computation that exceeds it produces a wrong answer with no indication. Ruby integers are arbitrary precision, so 2 ** 200 is exact and overflow does not exist as a category — at the cost of every arithmetic operation going through an object. Ruby also has no separate integer division operator: 7 / 2 is 3 because both operands are integers, and 7.0 / 2 is 3.5, which is the C rule rather than OCaml's separate /..

OCaml's int option is a different type from int: the value cannot be used without deciding what to do about absence, and the compiler lists the case you forgot. Ruby's nil is an ordinary object the same variable might hold, so found + 1 is valid code that raises NoMethodError only when find_even happened to return nil. Ruby's partial mitigation is the safe-navigation operator &., which short-circuits to nil rather than raising — useful, and still not a type. Note &:even?, which turns a symbol into a block and is covered in the blocks section.

OCaml destructures a tuple in a let and a list in a match, and its list pattern can only bind a tail — first :: rest. Ruby's splat collects the remainder and can appear anywhere in the pattern, so head, *, tail takes the ends and discards the middle in one line. It also works in method parameters and at call sites. What OCaml has that Ruby does not is the guarantee: a list pattern that does not cover every shape is a warning, where Ruby quietly assigns nil to anything the right-hand side did not supply.

A symbol is an interned name: :pending needs no declaration, is the same object everywhere it appears, and compares in constant time — the same properties an OCaml polymorphic variant tag has, and the same as an Erlang atom. What OCaml adds is that the type system tracks which tags a value may carry, so a function accepting [`Pending | `Active] rejects anything else and the match is checked. Ruby's case above returns nil for an unknown symbol and says nothing. Symbols carry a great deal of Ruby: hash keys, method names, and every option in every library API.

An OCaml string is a byte sequence with no declared encoding, so String.length counts bytes — 6 for this five-letter word — and uppercase_ascii says in its own name that it leaves anything non-ASCII alone. A Ruby String carries its encoding, so length counts characters, bytesize counts bytes, and upcase is fully Unicode-aware. That is a straightforward improvement, and it is why Ruby has an Encoding class and OCaml needs a library such as Uutf.

OCaml strings are immutable outright, with Bytes as the mutable counterpart. Ruby strings are mutable objects, and a literal in Ruby 4.0 is chilled: "hello".frozen? is false, mutating one works, and doing so warns that it will be frozen in a future release. Adding # frozen_string_literal: true to a file makes that mutation a FrozenError today. The safe way to build a mutable string is +"" or String.new, which neither warns now nor breaks when the default flips. Note <<, which appends in place — where + would allocate a new string.

A Ruby regex is written between slashes, is an object of class Regexp, and is woven through the string API: match, scan, gsub, split and case/when all take one. OCaml has no regular expressions in its standard library — Str is a separate library with a stateful, non-reentrant API, and serious code reaches for re from opam. That is a real ergonomic gap for text-processing work and one of the clearer wins on this page, alongside the encoding-aware strings.

OCaml's list is an immutable linked list, so 0 :: numbers builds a new list and both exist. Ruby's Array is a mutable dynamic array: unshift, push, sort! and map! modify in place. The convention that saves you is the bang suffix: sort returns a new array and sort! sorts in place, so a method ending in ! is announcing that it mutates. It is a convention rather than a rule — unshift mutates and has no bang — but it holds across the standard library and most gems.

OCaml's find_opt returns an option, so absence cannot be skipped. Ruby offers three: ages[:missing] returns nil silently, ages.fetch(:missing) raises KeyError, and ages.fetch(:missing, default) returns the default. Prefer fetch — the silent nil is where a typo in a key becomes a NoMethodError three call frames later. Hashes preserve insertion order, and the { ada: 36 } literal with symbol keys is so idiomatic that it doubles as keyword-argument syntax.

OCaml has no range type: a sequence of integers comes from List.init or a fold, and slicing a list means List.filteri or a helper. Ruby's Range is a real object built by .. (inclusive) or ... (exclusive), it works for anything comparable with a successor including strings and dates, it is lazy so (1..Float::INFINITY) is usable, and it can appear as a case condition or an array slice. It is a small feature that removes a surprising amount of boilerplate.

OCaml's List.sort takes a three-way comparison — the C convention, with its negative-zero-positive contract to remember. Ruby has both: sort with a block taking two arguments and <=>, and sort_by which takes a key function called once per element. sort_by is faster for an expensive key and has no convention to get wrong, and the same idea gives min_by, max_by and group_by. Note that sort returns a new array while sort! sorts in place — the bang convention again.

OCaml's Set.Make (Int) builds a module specialized to integer elements and every operation goes through it. Ruby's Set is a class whose elements need only implement hash and eql?, with |, &, - and ^ for the set algebra. The trade is the familiar one: OCaml's set is persistent so union leaves both operands intact, while Ruby's is mutable and first |= second modifies first in place, visible through every other name for it.

OCaml passes a function value like any other argument. Ruby gives the last argument special syntax: a block written in braces or do…end after the call, invoked with yield, and not appearing in the parameter list at all. That one piece of syntax is why each, map, times, open and every DSL in Rails read as they do — the closure is visually part of the call rather than an argument inside it. The cost is that a block is not a value: it cannot be stored or returned without converting it, which the next row is about.

OCaml has one function type and no distinctions. Ruby has a block (syntax, not a value), a proc and a lambda. A lambda checks its argument count and return returns from the lambda; a proc ignores extra arguments, fills missing ones with nil, and return returns from the enclosing method — which is surprising the first time. The & operator converts between a block and a proc in either direction, which is what map(&:even?) is doing: Symbol#to_proc turns :even? into a one-argument proc.

Both guarantee the cleanup runs however the body exits. OCaml's Fun.protect takes the body as a function and a ~finally; Ruby's method takes the body as a block and uses ensure, which is the finally of its exception mechanism. The reason this matters in practice is that Ruby libraries expose the block form as the primary API — File.open(path) { |file| … } closes the file, and the non-block form that returns a handle is the one you have to remember to close. That makes the safe path the short path.

Hash.new(0) returns a hash whose missing keys read as 0, so tally[word] += 1 needs no initialization check — which is the fiddly part of the OCaml column. each_with_object is a fold that threads a mutable accumulator, and inject is the immutable fold that corresponds to fold_left. And tally exists because counting occurrences is common enough that the standard library named it, which is the kind of thing Ruby does constantly and OCaml does not.

OCaml threads the value with |> because its List functions are curried and take the data last. Ruby's methods live on the object, so chaining needs no operator. select is filter (both names work), reduce is fold_left, and sum is the named shortcut. The &:even? form is Symbol#to_proc again. Both versions build an intermediate array at each stage; Ruby's lazy equivalent is .lazy, which is exactly OCaml's Seq.

Enumerable is a module defining about fifty methods in terms of one: each. Implement each, include the module, and your type gets map, select, sort_by, group_by, each_cons, lazy and the rest, all working correctly. OCaml's nearest equivalent is implementing a signature and applying a functor, which is checked and requires naming the module and instantiating it. Ruby's version is one include, needs no declaration, and is unchecked — if your each misbehaves, fifty methods misbehave. That trade is the whole language in miniature.

OCaml's Seq is a separate type with its own module, so code must choose between List and Seq up front and converting costs a traversal. Ruby's .lazy returns an Enumerator::Lazy that responds to the same Enumerable methods, so a pipeline becomes lazy by inserting one call and stays otherwise identical. Float::INFINITY as a range endpoint is idiomatic and works because the range is never materialized. This is the same capability with materially less friction.

Enumerable has around fifty methods, and the ones worth knowing on day one are group_by, partition, each_slice, each_cons, tally, sum, min_by/max_by, flat_map and zip. Every one is expressible as a fold in OCaml and none of them is in the standard library, so OCaml code writes the fold or reaches for a package such as Containers. This is the clearest everyday ergonomic difference between the two, and it costs nothing in safety — these are pure transformations.

In OCaml everything produces a value. Ruby is the same: if, case, begin and even a method definition all evaluate to something, so the assignment above needs no temporary and no repeated variable name. A method returns its last expression with no return needed, exactly as in OCaml. What differs is that a missing branch yields nil rather than being a type error — OCaml requires an if without else to have type unit, and Ruby just hands back nil.

OCaml has for and while as constructs and List.iter for collections. Ruby has for, while and until as keywords, and idiomatic code uses none of them: times, upto, step, each and each_with_index are methods taking a block. That is possible because the block syntax makes a closure per iteration feel free, and it is why a Ruby programmer rarely writes an index variable. Note 3.times — a method on an integer, which the everything-is-an-object section explains.

A statement modifier puts the condition after the expression, which reads as English and is idiomatic for short cases. unless is if not with its own keyword and is preferred when the negative reads better — though unless … else is universally considered a mistake. Together they produce the guard clause idiom: return early for the exceptional cases and leave the body unindented, which is how most Ruby methods are shaped. OCaml has neither, and its equivalent is a match or a nested if.

a&.b&.c evaluates to nil the moment any link is nil, without evaluating the rest — so a deep chain needs one operator per link and no nesting. OCaml needs Option.bind at each step or a let* defined first, and each step costs a line. What Ruby does not give you is the discipline: nothing forces the check, and a value that is never nil looks identical to one that might be. Note also || for the fallback, which fires on false as well as nil — a real difference from Ruby's otherwise clean truthiness rule.

Ruby 3.0 added case/in, which destructures arrays and hashes, matches against classes, binds sub-patterns with =>, supports alternatives with | and guards with if, and can deconstruct any object that defines deconstruct or deconstruct_keys. It is closer to OCaml's match than anything else in a mainstream dynamic language. Two differences remain: there is no type to be exhaustive over, and an unmatched value raises NoMatchingPatternError rather than being caught at compile time — which is at least louder than Python's silent fall-through.

A Ruby hash pattern is open by default: in { name: } matches any hash that has a name key and ignores the rest, and in { name:, **nil } demands exactly that key. It can also assert the value's class inline — name: String => name matches only when the value is a String and binds it. OCaml can match a record's declared fields and cannot express "at least these fields" or "and this one is an int", because a record's type already settles both. For data arriving as JSON this is genuinely useful.

OCaml's objects are structurally typed and genuinely interesting, and real OCaml uses records, variants and modules instead. Ruby has no alternative: a class is how you group data with behavior, and everything you call is built from them. attr_reader :owner is not syntax — it is a method call that defines methods, executed when the class body runs, and that is the mechanism the whole metaprogramming section rests on. Instance variables start with @ and spring into existence on first assignment, so a misspelling creates a second one that reads as nil.

Data.define arrived in Ruby 3.2 and builds an immutable value class: readers for each member, structural equality, a readable inspect, and a with method that is exactly OCaml's { record with field = value }. That is a genuine record, and it is what to reach for when the thing is a value rather than an object with behavior. The older Struct does the same and is mutable. Note the keyword-argument construction — Point.new(x: 0, y: 0) — which is the modern convention and much clearer than positional at the call site.

OCaml labels with ~ and defaults with ?, and needs a trailing () because a function with optional arguments cannot otherwise be known to be fully applied. Ruby needs no such marker: name: with no default is required and omitting it raises ArgumentError, while greeting: "Hello" is optional. Order does not matter at the call site. This is one of the few places where an OCaml habit transfers to a dynamic language and comes out cleaner.

OCaml has class inheritance in its object system and idiomatic OCaml does not use it — a variant when the kinds are closed, a record of functions when they are open. Ruby has single inheritance plus mixins, and both are ordinary. super with no parentheses passes the same arguments along, and super() with empty parentheses passes none — a distinction that catches everyone once. The NotImplementedError in the base class is Ruby's abstract method: there is no way to declare one, so raising is the convention.

An OCaml module is a first-class unit of abstraction — it can hide a type behind a signature, be parameterized by a functor, and be packed into a value. A Ruby module is a namespace and a collection of methods to mix in. It cannot hide anything (Ruby has no private types), cannot be parameterized, and is not a value you can pass. What it does instead is the subject of the next row, and it is genuinely useful — just not the same thing.

An OCaml functor takes a module of operations and produces a new module. Ruby's Comparable inverts it: the class includes the module and supplies <=>, and the module's methods are inserted into the class's lookup chain. The result is the same family of derived operations, obtained with one line and no instantiation to name. What is lost is everything the type system was checking: nothing verifies that <=> exists or returns a number until something calls a comparison. Comparable and Enumerable are the two mixins worth knowing by heart.

OCaml types are closed: an int has the operations the standard library gave it, and adding one means a function that takes an int. In Ruby every class is open, including the built-in ones, and reopening Integer to add a method makes it available on every integer in the process — including inside gems that have never heard of you. That is how Rails gets 3.days.ago and "foo".pluralize, and it is how two gems can break each other by defining the same method. The modern discipline is refine, which scopes a change lexically, and it is used far less than it should be.

This is the mechanism behind almost everything that makes Ruby feel magical. A class body executes when the file loads, define_method adds a method from a block, method_missing catches calls to methods that do not exist, and instance_variable_get reaches inside an object by name. Together they are how ActiveRecord gives you a method per database column without anyone writing them. OCaml's equivalent is a ppx rewriter operating on the parse tree at build time — more predictable, fully typed, and considerably harder to write.

instance_eval runs a block with self rebound to another object, so bare method calls inside the block dispatch to that object. That is the whole mechanism: the block is ordinary Ruby, and the "language" is just methods on a receiver you cannot see. It is genuinely expressive and it is also why an unfamiliar Ruby DSL can be impossible to navigate — the methods available inside the block are not visible from the block, and there is no type to ask. OCaml has no equivalent and would express the same thing as a data structure, which is duller and greppable.

send calls a method whose name is a string or symbol computed at run time, respond_to? asks whether an object has one, and methods lists them all. That is how a serializer walks an unknown object, how a test framework finds every method starting with test_, and how ActiveRecord answers find_by_email. OCaml has no equivalent — a function is not addressable by a computed name — so the same job is a dispatch table or a variant, which is more verbose, fully checked, and greppable. Note that send ignores private; public_send does not.

OCaml declares an exception with a keyword and catches it by pattern, binding the payload. Ruby's exceptions are classes inheriting from StandardError, caught by class with rescue, and they carry a message and a backtrace. Two conventions matter: always inherit from StandardError, not Exception, because a bare rescue catches the former and would otherwise miss yours; and a bare rescue => error is the idiom for "any ordinary error". Because Ruby has no result in general use, exceptions carry nearly all error handling — a missing key, a failed parse, a bad conversion.

OCaml's result means the caller cannot reach the value without deciding what to do about the error. Ruby raises: the standard library raises, gems raise, and a caller who writes no rescue lets the exception travel up. That is not always worse — an error nobody can handle locally is better propagated than threaded through every signature — but it does mean the set of exceptions a method may raise is documentation rather than type. Note Integer(text), the strict conversion that raises, versus text.to_i, which returns 0 for unparseable input and is a common source of silent wrong answers.

ensure is Fun.protect's ~finally and runs however the block exits. retry has no OCaml counterpart at all: it restarts the begin block from the top, which makes a bounded retry loop three lines with no recursion. Two cautions worth taking seriously. rescue with no class catches StandardError, not Exception — which is correct, because catching Exception would swallow Interrupt and SignalException. And a retry with no bound is an infinite loop that looks like error handling.

In OCaml the question does not arise: a list cannot be modified, so two names for one list are indistinguishable from two lists. In Ruby alias_name = original binds a second name to the same object, and every mutation through either is visible through both. dup makes a shallow copy and clone also copies the frozen state; a deep copy needs Marshal or a library. The rule worth internalizing is that assignment never copies in Ruby — it binds a name to an existing object — and this is invisible until something mutates.

OCaml is immutable by default and you opt in with mutable or ref. Ruby is mutable by default and freeze is the opt-out — per object, shallow, and permanent for that object's lifetime. Freezing a hash prevents adding keys and does not freeze the values inside it. For a value type Data.define is the better tool, since instances are frozen from birth and it supplies the with that makes functional update pleasant. Reaching for Data where you would write an OCaml record is the single habit most worth carrying over.

The strongest argument for Ruby is not a language feature: it is Rails, which after twenty years is still the fastest route from nothing to a working database-backed application, and which is only possible because of open classes and blocks. Add irb and binding.irb, which drop you into a live object graph mid-request; a testing culture forced into existence by the absence of a compiler and correspondingly excellent; and a standard library and gem ecosystem that cover almost everything with unusually good documentation. Against that, OCaml offers proof, and asks you to assemble the rest.

Four transfer directly. Use Data.define for value objects — frozen, structurally equal, with a with method, and the closest thing to a record. Model states as classes and match with case/in, which gets you destructuring and a loud NoMatchingPatternError instead of a silent fall-through. Keep methods small and total, returning a value on every path rather than nil on some. And prefer fetch to [] so a missing key fails where it happened. None of it is checked; all of it still works, and it is what distinguishes Ruby written by someone who has used a type system from Ruby written by someone who has not.

Every operation goes through method dispatch on an object, and although YJIT has narrowed the gap considerably for real workloads, CPU-bound numeric code remains one to two orders of magnitude slower than native OCaml. The other constraint is the global VM lock: threads are real OS threads but only one executes Ruby at a time, so CPU-bound work gets no parallelism from them — the escapes are processes, Ractors (still experimental after several years), or a C extension. If the hard part of the problem is computation rather than expressing the domain, this is the wrong tool.