An interview with Laurent René de Cotret, Chair of the Haskell Foundation and engineer at Bitnomial, covering Haskell's industrial adoption challenges, the role of type safety and effect tracking in a production financial exchange, and the future of Haskell in data science. Key topics include: why Haskell tooling and education remain friction points, how Bitnomial uses Servant to push type guarantees across system boundaries, a practical framework for deciding when advanced types are worth their complexity cost (using a one-way vs. two-way door analogy), and why effect systems like Haskell's STM are underappreciated in mainstream software engineering.
Table of contents
You recently became Chair of the Haskell Foundation at a particularly important moment: the Foundation is moving away from having an executive director and toward a new structure with a committee responsible for shaping a unified technical vision. From your perspective, what are the most important problems the Haskell ecosystem needs to solve over the next three to five years, and where can the Foundation make a difference that individual companies or open-source maintainers cannot?You’ve said that one of your goals is to expand Haskell’s reach in industry, and today you work at Bitnomial, whose backend is built entirely in Haskell. After seeing Haskell from both the community and production sides, what do you think actually prevents more companies from adopting it: the learning curve, tooling, hiring, ecosystem maturity, perceived business risk, or something else?What advantages does Haskell offer a business like Bitnomial?Your Haskell Ecosystem Workshop talk is titled “Servant at Bitnomial — Expanding type-safety from applications to systems.” Where do you think the boundary of useful type safety lies in a real financial system? How far can invariants be pushed into types before the abstractions begin to impose unacceptable complexity on developers?In your “Servant by Construction” series, you deliberately rebuild parts of Servant to demystify advanced type-level programming. Haskell is often praised for abstractions that make invalid states unrepresentable, but those same abstractions can make a codebase difficult for newcomers to understand. What have you learned about designing sophisticated typed systems that remain approachable, debuggable, and maintainable by an engineering team?Your background spans experimental physics, scientific computing, quantitative research, energy infrastructure, and now exchange and clearinghouse software. How has moving between these domains changed the way you think about correctness?Are there lessons from scientific computing that mainstream software engineering should integrate?You have explored typed dimensions for scientific computing, type families for trading features, and higher-kinded types for dataframe-like structures. Why do you think Haskell has never achieved the same position in data science and numerical computing that Python or Julia have, despite its ability to express domain constraints so precisely? What would need to change for Haskell to become genuinely competitive there?You maintain or contribute to projects across very different parts of the ecosystem, including Cloud Haskell, Beam, and Hakyll, while also working in industry and leading the Haskell Foundation. Looking across the ecosystem as a whole, which Haskell ideas or technologies do you believe are genuinely underappreciated today: things that could influence mainstream software engineering much more broadly over the next decade?Questions this post answers
How does Bitnomial use Servant to enforce type safety across system boundaries in Haskell?
Bitnomial uses Servant as a type-level API DSL to move correctness guarantees from individual applications to entire systems. Engineers are expanding its use at system boundaries, including role-based permissioning of endpoints powered internally by singleton types while keeping a straightforward developer-facing interface. GHC extensions scoped to single modules allow complex type machinery to be encapsulated behind clean APIs. Teams building type-safe Haskell APIs track Servant patterns and ecosystem developments on daily.dev.
How should I decide when advanced type-level programming in Haskell is worth the added complexity?
A useful heuristic mirrors Jeff Bezos' one-way vs. two-way door analogy: if extra type safety prevents unrecoverable issues — security vulnerabilities, data loss or corruption — the complexity cost is worth paying. If it only prevents recoverable issues, such as cache data loss, it is acceptable to compromise and spend the complexity budget elsewhere. Encapsulation via module-scoped GHC extensions can also hide complexity from everyday users. Developers navigating Haskell type system trade-offs find real-world case studies and discussions on daily.dev.
Why hasn't Haskell succeeded in data science and numerical computing the way Python has?
Python gained early traction in scientific communities because non-programmers could be productive quickly, which seeded the NumPy/SciPy/Matplotlib ecosystem. Decades of compounding growth left Haskell behind. For Haskell to compete, it needs baseline usability for non-programmers — interactive notebooks, plotting, numerical routines — and a killer application that makes it the clearly best tool for a specific important problem, potentially via projects like Accelerate. Developers watching the Haskell ecosystem evolve keep up with projects like DataHaskell and Accelerate on daily.dev.