OCaml.CodeCompared.To/Go

OCaml's let () = … binds the unit pattern, which runs the expression and asserts it produces nothing. Go requires a package main declaration, an import for anything outside the language itself, and a function called main. The import is not optional and not decorative: an unused import is a compile error, which is the first sign of a language that treats unfinished code as broken code rather than as work in progress.

OCaml's format string is a value of the built-in format type, so the compiler reads %s and %d and requires exactly a string then an integer — a mismatch is a compile error. Go's is an ordinary string and Printf is variadic over any, so a mismatch compiles and prints %!d(string=Go) at runtime. In practice go vet catches it and runs as part of go test, which is the pattern to expect throughout: Go moves checks the compiler could do into tooling. Note :=, which declares and infers in one step.

OCaml splits the job: opam installs packages into a switch you activate, and dune compiles against whatever that switch holds — so a build depends on shell state the project files do not record. Go has one binary that builds, tests, formats, vets, fetches dependencies and manages versions, with no environment to activate and no global state: go.mod plus go.sum fully determine the build. There is also no separate build-configuration language — no dune files, no Makefile — because the directory layout is the configuration. That is a real operational advantage and it is one of the main reasons teams pick Go.

The OCaml version composes three combinators and reads declaratively. The Go version writes the loop out, and Go's designers would say that is better: there is one obvious way to write it, every reader recognizes it immediately, and there is nothing to learn before you can modify it. Go optimizes for a large team reading unfamiliar code, not for the person writing it. Whether that trade is right depends entirely on the situation, and an OCaml programmer who arrives expecting to write OCaml in Go's syntax will be unhappy and will write code their colleagues dislike. The rest of this page is easier to read with that in mind.

gofmt has no options. That was a deliberate decision to end formatting arguments by removing the thing being argued about, and it worked — Go code from any two projects looks the same, diffs contain only real changes, and no team spends a meeting on brace placement. OCaml has ocamlformat, which is excellent, optional, and configurable, so projects differ and adopting it on an existing codebase is a decision with a large diff attached. The Go convention also explains the tabs you will see in every example on this page.

This is genuinely better than C, where reading an uninitialized local is undefined behavior. It is also weaker than OCaml, where the compiler makes you supply every field and there is no "default" to fall through to. The cost shows up as a category of bug OCaml cannot have: a struct that was never properly initialized is indistinguishable from one deliberately set to zero, so "was this configured?" and "was this configured to zero?" are the same question. Go's answer is the convention that the zero value should be useful — an empty sync.Mutex is an unlocked mutex, an empty bytes.Buffer is ready to write to — which works well when the type is designed for it and not at all when it is not.

OCaml is immutable by default and you opt in with mutable or a ref. Go has no immutability for composite values: const applies only to numbers, strings and booleans, so a struct, slice or map is always writable by anyone holding it. What partly rescues this is that a struct assignment copies — shifted := origin above duplicates the value, so mutating one does not affect the other, which is why the output is 0 5. That does not hold for slices, maps or pointers, which is the subject of the collections section and the most common source of aliasing bugs in Go.

OCaml discovers a function's type and generalizes it automatically, so count works for any element type with nothing written down. Go requires every parameter and result, and getting the same generality needs an explicit type parameter — [T any], available only since Go 1.18. Inside a body, := declares and infers. Note the shorthand first, second int, which gives both parameters one type; and note that an unused local variable is a compile error, not a warning, which is the same strictness as the unused import.

C will silently widen an int to a double; Go will not, and neither will OCaml. Go goes further than most: int, int32 and int64 are three distinct types that do not mix without a conversion, even where the widths happen to match. The difference from OCaml is only in spelling — OCaml gives floats their own operators (/.) while Go overloads / and distinguishes by the operand types, so count / 2 is integer division and float64(count) / 2.0 is not.

A Go string is an immutable byte slice, so len is 6 here just as OCaml's String.length is — but Go's is documented to be UTF-8 where OCaml's has no declared encoding. The payoff is that range over a string decodes it and yields rune values (Go's name for a Unicode code point), so the accented letter arrives whole where OCaml's String.iter hands you two mojibake bytes. Indexing with text[0] still gives a byte in both. This is one of the few places Go is straightforwardly ahead of OCaml.

strings.Join is String.concat with the arguments the other way round, and strings.Builder is Buffer. The reason both languages ship a builder is the same: strings are immutable in both, so appending in a loop reallocates and copies each time, giving quadratic behavior on long inputs. Note the zero-value convention from earlier at work — var builder strings.Builder needs no constructor because the zero value is a usable empty builder.

A Go slice is a three-word header — pointer, length, capacity — over a backing array, so slicing does not copy and two slices can write to the same memory. That makes view[0] = 99 visible through numbers. Worse, append reallocates only when capacity runs out, so whether a modification is shared depends on how much spare capacity the slice happened to have — the same code can alias or not depending on how the slice was built. OCaml's list makes the question impossible: it is immutable, so sharing is invisible. The Go habits are to copy explicitly when you mean to (slices.Clone) and to treat any slice you did not create as read-only unless documented otherwise.

OCaml's find_opt returns an option, so the absent case cannot be skipped. Go's ages["alan"] returns 0 — the zero value for int — with no indication that the key was missing, and the value, found := m[key] form is the only way to tell "absent" from "present and zero". That is the same trap as the zero-value row, and it is the single most common Go bug an OCaml programmer will introduce. Note also that map iteration order is deliberately randomized, so code that accidentally depends on ordering fails quickly rather than in production.

Go has slices.Sorted, slices.Contains and friends, and since 1.23 it has range-over-function iterators — but there is no map/filter/reduce in the standard library and idiomatic code does not reach for them. The single loop does the whole pipeline in one pass with no intermediate slices, which the OCaml version allocates two of. What is lost is composition: each stage of the OCaml pipeline is a value that can be named, reused and tested, while the Go loop is a block that does one specific thing.

OCaml's List.sort returns a new list and leaves the original alone, because the list is immutable. Go's slices.Sort and slices.SortFunc sort in place and return nothing, so the original ordering is gone unless you cloned first — which is why slices.Clone appears above. Both use the C convention of a comparison returning a negative number, zero or a positive one. Note that len(left) - len(right) is safe here because lengths are small; on arbitrary integers that subtraction can overflow, and the correct spelling is cmp.Compare.

In OCaml everything produces a value, so if can be bound directly and every branch must agree on a type. Go's if is a statement, so the variable is declared first and assigned in each branch — and if a branch is missed it silently keeps its zero value, which is the zero-value trap once more. The absence of a ternary is deliberate: the Go FAQ says nested ternaries become unreadable, so the language does without. An OCaml programmer will find this the most tiring difference in daily use.

Go fixed C's worst default: cases do not fall through, so no break is needed and fallthrough must be asked for. A bare switch with no subject takes boolean cases, which is how a guard is expressed, and comma-separated values give an or-pattern. What it cannot do is destructure — there is no binding of sub-parts, no nested patterns, and no exhaustiveness checking anywhere. The default above is not optional politeness; without it the function would fall off the end, which Go reports as "missing return".

OCaml's Fun.protect takes the body as a function and a ~finally to run afterwards, which works and reads as a higher-order call. Go's defer registers the cleanup at the point you acquire the thing and runs it when the enclosing function returns — so file, err := os.Open(…) followed immediately by defer file.Close() puts the two lines together, which is genuinely easier to get right than remembering a wrapper. Deferred calls run last-in-first-out and their arguments are evaluated immediately, which is the one surprise: defer fmt.Println(counter) prints the value at the defer, not at return.

for with three clauses counts, with one clause it is a while, with none it loops forever, and with range it iterates. OCaml has for … to and while as separate constructs, and its while needs a ref because there are no mutable local bindings. Since Go 1.22 for range 3 also counts without a variable, which is the newest and tersest form. Go has break and continue, plus labeled versions for breaking out of nested loops — OCaml has none of these, so an early exit means recursion or an exception.

Go functions take exactly their parameters, positionally, with no defaults and no names at the call site. Partial application means writing a closure out, as above. The community answer to optional configuration is either an options struct or the "functional options" pattern — a variadic list of func(*Config) values — which is verbose enough that most APIs simply require all their arguments. Go does have variadic parameters (parts ...string) and multiple return values, which is what it uses instead of tuples.

OCaml returns a tuple — one value that happens to have two components, which can be named, stored, passed on and pattern-matched. Go returns two values, and there is no type that holds them: you cannot store the result of divideAndRemainder in a single variable, pass it onward as one thing, or make a slice of them. That is why (T, error) is a returning convention rather than a Result type, and why Go's error handling cannot be composed the way OCaml's result can. It is the most consequential small difference on the page.

The two are the same idea. OCaml needs a ref because it has no mutable local bindings, so the counter lives in a heap cell; Go's total is an ordinary local that the closure captures, and the compiler moves it to the heap automatically because it escapes. The anchor column sequences its three calls on purpose, and the comment says why: OCaml does not specify the order in which a function's arguments are evaluated and in practice evaluates right to left, so Printf.printf "%d %d %d" (next ()) (next ()) (next ()) prints 3 2 1. Go evaluates arguments left to right. That is a genuine trap in both directions and a good reason not to put side effects in arguments.

OCaml keeps data and the functions over it separate — area is a plain function whose first argument is a rectangle. Go's receiver syntax gives the same function dot-call notation and lets the type satisfy interfaces, which is the whole mechanism the next section rests on. Two details matter: the receiver may be a value (a copy, as here) or a pointer (func (r *Rectangle)), and only a pointer receiver can mutate; and capitalization is visibility — Width is exported from the package and width would not be, which is Go's entire access-control system.

Writing Engine with no field name embeds it, and every method and field of Engine becomes callable directly on Car. That saves the delegating functions the OCaml column writes by hand. What it is not is inheritance: there is no subtyping, a Car is not an Engine, and there is no virtual dispatch — Describe on the embedded value cannot be overridden in a way the embedded code will call. Go has no inheritance at all, which is another deliberate subtraction.

OCaml has no JSON in its standard library; yojson with ppx_deriving_yojson supplies it, and the derived conversion is generated at compile time and type-checked. Go's encoding/json reads struct tags by reflection at run time, so json:"name" is an ordinary string the compiler never validates — misspell it as jsonn:"name" and the field silently marshals under its Go name. That is the trade Go makes repeatedly: reflection gives you a serializer that works for any struct with no code generation, at the cost of moving errors from compile time to run time. go vet does check tag syntax, which recovers part of it.

An OCaml variant guarantees the set of cases is closed and that every one is handled. Go's nearest construction gives neither. The unexported isShape() marker keeps other packages from adding cases, which is a real if partial substitute for closedness — but nothing prevents a fourth type in this package, and the type switch has no exhaustiveness check at all, so adding Triangle silently falls through to that trailing return 0. The trailing return is not defensive style; the compiler requires it because it cannot prove the switch covers everything. Linters (exhaustive) can check this, and are not run by default.

OCaml's int option is a different type from int, so the value cannot be used without deciding what to do about absence. Go's pair is two independent values, so number, _ := findEven(…) compiles and hands you 0 — indistinguishable from finding a genuine zero. Go 1.18's generics do make a real Option[T] possible to write, and the community mostly does not, because it does not compose with the standard library and reads as foreign. Note that this is the same shape as the map lookup and the error return: Go has one idea, a second boolean or error result, and uses it everywhere OCaml would use a sum type.

OCaml's status has exactly three values and no way to produce a fourth. A Go named integer type accepts any integer: Status(42) compiles, which is why the trailing return "unknown" is a necessity rather than defensive clutter. What Go adds is the String() method — implementing fmt.Stringer means fmt.Println formats the value automatically, which is a genuinely nice piece of interface design. The stringer code generator writes that method for you, and go vet can be extended to check exhaustiveness, but neither is on by default.

An OCaml signature constrains a module, and the caller must name that module. A Go interface constrains a type, structurally: Number never mentions Describable, and satisfies it by having a matching method. That means you can define an interface for a type somebody else wrote, after the fact, which is genuinely powerful — the standard library's io.Reader and io.Writer are one method each, and half the ecosystem composes through them. The Go convention that follows is worth adopting: define small interfaces at the point of use, not next to the implementation.

OCaml needs a first-class module, packed with (module English) and unpacked with (val …), because a module is not a value by default. In Go an interface value is a value — a pair of a type descriptor and a pointer — so a slice of them needs no ceremony. This is the ergonomic advantage of putting the abstraction on types rather than modules, and it is why Go code reaches for interfaces constantly where OCaml code reaches for them almost never. The cost is that dispatch is dynamic and unspecialized, where OCaml's functors resolve at compile time.

any is an alias for interface{}, the interface with no methods, which every type satisfies — so a value of that type carries no information the compiler can use, and getting anything out requires a type assertion or a type switch. It is Go's Obj.t, except ordinary rather than alarming, and it was the only way to write a generic container before 1.18. The default branch is mandatory in spirit: the set of types that could arrive is every type, so no switch over any can be exhaustive. Note the two-value assertion form, text, ok := value.(string), which reports failure instead of panicking.

"Accept interfaces, return structs" works because satisfaction is implicit: a caller can pass anything with the right method without either side coordinating, and returning the concrete type means the caller keeps every method rather than only the ones you chose to expose. The corollary is that interfaces belong at the point of use — describe declares the one method it needs — rather than beside the implementation, which is the opposite of the Java habit. OCaml's functor fixes the abstraction at instantiation instead, which is checked more thoroughly and is far less fluid.

OCaml infers 'a list -> 'a -> 'a and generalizes automatically — polymorphism is the default rather than a feature. Go needs [T any] written out, with a constraint interface saying what operations are allowed. Three real limits: methods cannot have their own type parameters, so a generic Map method on a type is impossible; there is nothing higher-kinded, so no abstraction over []T versus map[K]T; and constraints cannot express "has a field", only "has a method" or "is one of these types". The result is that generics are used for containers and small utilities and rarely for architecture.

OCaml exceptions propagate until something catches them, so a function that cannot handle an error need not mention it. Go has no exceptions for this purpose at all: an error is a value, every fallible call returns one, and the caller must decide something at every step. That is closer to OCaml's result than to its exceptions — except that nothing forces the check, since value, _ := check(500) compiles. Modern Go wraps errors with fmt.Errorf("...: %w", err) to build a chain, and inspects them with errors.Is for sentinel values and errors.As for typed ones, as above.

OCaml's binding operator collapses the chain to one line per step with the failure path written once; Rust's ? does the same in one character. Go has neither and has repeatedly declined to add one, on the grounds that error handling is program logic and should be as visible as any other logic — that a ? makes it easy to propagate an error without thinking about whether propagating is right. The counterargument is the column above: three-fifths of that function is machinery, and the repetition makes it easy to return the wrong variable. Both are true. It is the clearest case on this page of Go choosing explicitness over concision.

panic unwinds, running deferred functions on the way, and recover inside a deferred function stops it — so mechanically it is an exception. The convention is that it is only for programmer error: an impossible state, a broken invariant, a nil map write. Using it for expected failures is what the error return exists to prevent, and code review will say so. The legitimate exception is a library boundary, where a package may recover internally and return an error rather than let a panic escape. OCaml, by contrast, uses exceptions freely and idiomatically for ordinary control flow.

%w in fmt.Errorf wraps an error, producing a new one whose message adds context and whose chain still contains the original. errors.Is walks that chain comparing against a sentinel, and errors.As walks it looking for a type. That combination is genuinely good: an error can accumulate "looking up X: opening Y: permission denied" as it propagates while the caller can still ask "was this fundamentally a permission problem?". OCaml's exceptions carry a payload but have no wrapping convention, so context is usually added by catching and re-raising a different exception, which loses the original unless you carry it explicitly.

OCaml has no null at all: absence is option, a different type the compiler makes you handle. Go's nil is the zero value of six kinds, and their behaviors differ — a nil slice is fully usable (len is 0, append works, range does nothing), a nil map reads as zero values and panics on write, and a nil pointer panics on dereference. Knowing which is which is a real part of learning Go, and the useful nil slice is why Go code so rarely initializes one explicitly.

An interface value is a pair: a type descriptor and a value pointer. It is nil only when both halves are nil. Assigning a nil *MyError to an error gives an interface whose type half is set, so err != nil is true and the caller reports a failure that did not happen. The fix is to return a literal nil, never a typed nil pointer — which means never declaring an error variable of a concrete pointer type and returning it. OCaml cannot express the situation: None is None, with no room for a present-but-empty state.

An OCaml 5 Domain is an operating-system thread with its own minor heap, so the guidance is to create roughly as many as you have cores and schedule work across them with a library. A goroutine starts with a small growable stack and is multiplexed onto OS threads by the runtime, so a goroutine per request is the normal design and hundreds of thousands are unremarkable. Note also that since Go 1.22 the loop variables are per-iteration, so capturing index and value in the closure is safe — before that this exact code was the language's most famous bug, and older examples pass them as arguments.

Go builds CSP into the language: chan int is a type, <- is an operator, close ends a range, and select waits on several channels at once with a default for the non-blocking case. That last one has no OCaml equivalent at all and is what makes timeouts and cancellation composable. OCaml 5's standard library provides domains and mutexes and leaves channels, task pools and parallel iteration to Domainslib — a deliberate choice to keep the core small, and one that means the ergonomic layer is a dependency rather than a given.

The two columns are structurally identical, and both leave it to the programmer to remember the lock — delete the locking in either and the program still compiles and quietly loses increments. Two Go details worth having: go test -race and go run -race ship with the toolchain and reliably find exactly this bug, which is a much better safety net than OCaml offers; and the zero value of a sync.Mutex is an unlocked mutex, so var lock sync.Mutex needs no constructor. Go's own slogan is "share memory by communicating" — prefer a channel to a mutex where the shape allows.

select blocks until one of several channel operations can proceed, picking randomly among those that are ready, and a default case makes it non-blocking. Because a timer is just a channel (time.After returns one), a timeout is an ordinary case rather than a special mechanism — and so is cancellation, since a context.Context exposes a Done() channel. That uniformity is the real design achievement: waiting, timing out and cancelling are one construct. OCaml 5 has no equivalent in the standard library; Eio provides structured concurrency with cancellation, and it is a library choice.

context.Context carries a cancellation signal, a deadline and request-scoped values, and the standard library takes one in every blocking call. The cost is that it colors your function signatures exactly the way async does in other languages: adding cancellation at the bottom of a call chain means adding ctx to every function above it. OCaml 5's effect handlers are the interesting contrast — a handler can implement cancellation without the intervening functions knowing, which is precisely the coloring problem Go solves by giving in to it and Rust solves by giving in to it differently.

OCaml modules are a language construct: they nest, can be defined inline, can be constrained by a signature, passed to a functor and packed into a value. A Go package is a directory of files that share a namespace, and that is the whole of it — no nesting, no signatures, no functors. Visibility is decided by capitalization of the identifier, which is unusually blunt and unusually memorable. What Go adds instead is a strict rule against import cycles, which forces a directed dependency graph and is a real architectural benefit on a large codebase.

A functor takes a module of types and operations and produces a module. Go has no module-level parameterization at all, and the substitute is a constrained type parameter — cmp.Ordered is a constraint listing the types that support <. That covers "one type with a standard capability" neatly. What it cannot do is bundle a type with its operations so the pairing is checked and supplied once: there is no way to say "this type comes with this comparison" and have the compiler thread it through, so an alternative ordering means passing a comparison function at every call, as slices.SortFunc does.

Go ships testing in the standard library and go test in the toolchain, with table-driven tests as the near-universal convention, benchmarks (func BenchmarkX), fuzzing (func FuzzX), coverage and the race detector all built in. Nothing is chosen and nothing is installed, so every Go codebase tests the same way. OCaml has excellent testing libraries — Alcotest, QCheck for property testing — and choosing among them is a decision each project makes, which is the same small tax the web-framework choice imposes. Note the naming rule: a test file ends in _test.go and a test function starts with Test.

Go's standard library contains a production HTTP server, TLS, JSON, a test framework, a race detector, a profiler and a formatter — so a service needs no dependency to exist and few to grow. Compilation is fast enough to feel instant, the output is a single static binary that copies to a container with no runtime, and the concurrency model means a request handler is just a function. Against that, OCaml gives you a far better type system and asks you to choose a web framework, choose a concurrency library, and accept that the ecosystem is smaller. Which side wins depends on whether the hard part of the problem is in the types or in the operations.

You cannot make illegal states unrepresentable in Go — no variant, no exhaustiveness, and a struct always has every field. What you can do is keep the fields unexported and expose only constructors that produce valid values, so the illegal states are unreachable from outside the package even though the compiler cannot prove it. The same applies throughout: keep functions small and total, return errors rather than partial results, prefer values to pointers so aliasing cannot surprise you, and put the type's invariants behind its package boundary. None of it is checked. All of it still works.

The race detector is the one worth singling out: go test -race instruments memory access and reliably reports data races with both stack traces, and it ships with the compiler. OCaml has no equivalent, and its runtime guarantees only that a race cannot corrupt memory — you still get a wrong answer with nothing to point at. Add the built-in profiler, coverage, benchmarking, documentation server and dependency management, and the toolchain becomes a large part of the honest case for Go. OCaml's pieces are individually excellent and are assembled per project, which is a real if smaller cost paid on every new repository.