Richard Eisenberg
Programming-languages researcher and software engineer at Jane Street, where he works on the Tools and Compilers team — specifically on the front end of the OCaml compiler, the part responsible for language features, type checking, and type inference. He came to Jane Street after years as one of the most active contributors to Haskell’s type system: a PhD under Stephanie Weirich at the University of Pennsylvania, a professorship at Bryn Mawr College (where open-source work counted as scholarship), and a research role at Tweag, a Haskell consultancy in Paris. He remains Chair of the Haskell Foundation and a member of the GHC Steering Committee — the body that governs how Haskell evolves — while working in OCaml daily.
His signature research interest is dependent types: type systems expressive enough to encode a correctness proof directly in a function’s signature, so the compiler verifies the proof on every build. In Haskell, he spent years extending GHC toward dependent-type support. At Jane Street, he has turned that interest toward unboxed types — a design that eliminates OCaml’s hidden performance cost of representing almost everything as a heap pointer, while preserving the type safety and ergonomics that make the language productive at scale.
Core positions
Eisenberg holds that a programming language is first and foremost a medium of precise communication — between programmer and computer, and between programmers — and that this purpose is not weakened by AI-assisted coding but reinforced by it. Generated code still has to be read and verified; a machine-checkable specification gives that verification a formal target. His worry about AI is the closed-loop failure mode: if programmers delegate writing the specification to the model, they lose the ability to judge whether what they received is correct.
On language design, he is a consistent advocate for the ‘pay-as-you-go’ principle: powerful features should impose zero cost on code that does not use them. He views Rust’s pervasive lifetime annotations as a counter-example — precise memory control is bought at the price of every programmer paying the annotation burden all the time. His preferred path for OCaml is garbage collection and uniform types by default, with opt-in unboxed and stack-allocated types for the code paths where layout and latency matter.
He also thinks language extensions, as Haskell has accumulated them, are a user-experience problem: 150 flags make it impossible for newcomers to distinguish settled convention from dangerous experiment. He wants the GHC Steering Committee to consolidate toward something closer to a single standard language.
In the wiki
- Richard Eisenberg on The Future of Programming — Signals and Threads, 18 May 2023: dependent types, unboxed types, OCaml versus Haskell, and what AI pressure means for language design