Xavier Leroy on programming, languages and formal verification

**TL;DR:** Xavier Leroy discusses OCaml’s strengths (functional, predictable, good GC), contrasts it with Rust and JavaScript, and explains type inference via constraint solving. ## Interview Background In this interview, Xavier Leroy, creator of the OCaml programming language, shares his views on programming language design, formal verification, and memory management. He responds to questions about Rust, JavaScript, and the difficulty of learning functional languages, and explains in depth how type inference works. ## OCaml’s Design Philosophy and Strengths ### Blending Functional and Systems Programming OCaml is an excellent functional language, supporting inductive types, pattern matching, higher-order functions, and more, while also being a forward-looking systems programming language. It fully supports imperative programming, with control structures such as exceptions, threads, and user-defined effect handlers. ### Predictable Cost Model Leroy emphasizes that OCaml’s cost model and execution model are very predictable: “When you write code, you know very well what will be time-consuming, what will be fast, and what will be slow.” In contrast, many functional languages are unstable in this regard. OCaml’s compiler generates efficient code and comes with a low-latency garbage collector (GC), making it suitable for scenarios like network programming. ### Early Adopters from Systems OCaml was initially used for theorem proving and domain-specific languages. Later, Cornell University’s Ensemble project (a network protocol stack for reliable multicast) ported code from C to OCaml, resulting in more elegant, more evolvable code with performance comparable to C. They also ran the GC during idle packet transmission times, achieving “zero-cost” reclamation. Another important user is Jane Street, which uses OCaml to build trading infrastructure, valuing its speed, reliability, absence of long pauses, and readability even for non-programmers. ## The Boundary Between Rust and OCaml ### Memory Management: Automatic vs. Manual Leroy points out that the main difference between OCaml and Rust lies in memory management: OCaml uses automatic GC, while Rust is a manual memory management language. “As far as I know, it is the best language for manual memory management. It makes it basically safe through rules like borrowing and tracks ownership, etc. But it is still a language where you allocate and free memory yourself.” This makes programming safer but also more demanding. ### Performance Trade-offs Are Not Absolute Although manual memory management is often considered faster, Leroy adds: “Manual memory management is not always faster, or you need very good programmers to always be faster.” For example, in C++, copying objects many times because unique ownership is not clear leads to time and memory bloat. GC languages have an advantage when sharing data structures; Rust’s ownership rules may force unsharing, using more memory. ### Attempts at “Hybrid Management” Jane Street’s Oxidized OCaml project attempts to stack-allocate certain data structures, hoping to combine the benefits of manual and automatic management. But Leroy’s experiments showed limited gains: short-lived objects are already cheap under GC; long-lived objects bear more scanning overhead, and stack allocation doesn’t help them. ## Criticism of JavaScript Leroy admits he is not a fan of JavaScript. “It is very dynamic. Type checking is entirely dynamic, and almost everything can be redefined at runtime—including the semantics of method calls.” This extreme dynamism makes programs fragile and introduces security risks. He sees JavaScript as the “ultimate dynamic language,” while OCaml is very static. However, he acknowledges that JavaScript contains a functional core inside (similar to Lisp), and its designer Brendan Eich was influenced by Lisp. But he criticizes JavaScript’s meta-object protocol (which allows modifying the semantics of basic operations like method calls) as a “security nightmare” that is easily misused. ## The Learning Difficulty of Functional Languages Leroy believes functional programming is not inherently harder, especially for people with a mathematical background. He quotes Rob Pike, noting that Google hires many fresh graduates, so they choose simpler languages. Companies like Jane Street use OCaml as a filter, attracting applicants with more interesting backgrounds. He also mentions that Python is 50% a functional language, so people familiar with Python already have one foot in functional programming. ## Type Inference: Principles and Examples ### Core Idea Type inference allows programmers to omit most type declarations because the compiler can deduce types from usage. For example, `X = string length of S` lets you infer that `S` is a string and `X` is an integer. ### How the Compiler Works Leroy explains that the compiler collects a set of constraints and then solves them. If there is no solution, it reports a type error; if there are multiple solutions, it selects a predictable standard solution. Programmers can still add explicit type annotations to enhance documentation and readability. ### A Simple Example (Partial Transcription) Although the transcription is cut off here, Leroy begins an example: “Suppose there is a function with two parameters, X and Y...” Type inference works by analyzing expressions like this and generating and solving systems of constraint equations. --- **Source:** Xavier Leroy on programming, languages and formal verification – YouTube (https://www.youtube.com/watch?v=9Cswiqrq6So)