Mercury argues that Haskell's type system makes entire classes of financial bugs structurally impossible, not just unlikely. With 2 million lines of Haskell processing real banking transactions and managing billions in deposits, they contend that types can encode business invariants — such as ensuring account balances can't silently go wrong — providing compile-time safety that is critical in a zero-tolerance regulatory environment.
The blog post directly challenges the narrative that Haskell doesn't scale for production use. At roughly 2 million lines, Mercury's codebase is one of the largest known production Haskell deployments, and the company continues to actively write more Haskell — demonstrating that the language handles real-world concerns like build systems, compile times, deployment pipelines, and hiring at meaningful scale.
The editorial frames Mercury's 2M-line codebase as 'an inconvenient data point' for Haskell critics. It emphasizes that for a language routinely dismissed as academic or impractical, Mercury demonstrates that Haskell scales to millions of lines, handles regulated financial workloads, and remains the team's language of choice for new development.
Mercury, the fintech company offering banking services to startups and managing billions in customer deposits, published a detailed engineering blog post revealing that their core platform runs on roughly 2 million lines of Haskell. This makes Mercury's codebase one of the largest known production Haskell deployments in the industry — potentially the largest outside of Meta's Sigma anti-abuse system (which itself was a custom Haskell dialect).
The post, published on the official Haskell blog, walks through the nuts and bolts of running Haskell at this scale: build systems, compile times, deployment pipelines, hiring, and the daily reality of maintaining a typed functional codebase that processes real financial transactions. It landed on Hacker News with a score of 234, triggering exactly the kind of debate you'd expect — part admiration, part skepticism, and a healthy dose of "but does it scale?"
For a language that critics routinely dismiss as academic or impractical, Mercury's codebase is an inconvenient data point: Haskell scales to millions of lines, handles regulated financial workloads, and the company is still choosing to write more of it.
### The correctness trade-off has real numbers now
The perennial argument for Haskell (and strong static typing generally) is that the type system catches bugs at compile time that would otherwise show up in production. For most teams, this remains a theoretical claim backed by anecdotes. Mercury is one of the few companies operating at sufficient scale, in a sufficiently high-stakes domain, to provide meaningful signal.
Banking software has zero tolerance for certain categories of bugs. An off-by-one error in a ledger calculation isn't a UI glitch — it's a regulatory incident. Mercury's argument is that Haskell's type system makes entire classes of financial bugs structurally impossible, not just unlikely. Types encode business invariants: an account balance can't silently become negative, a transaction can't reference a nonexistent account, currency conversions are tracked at the type level. These aren't unit tests that someone might forget to write. They're compiler-enforced constraints.
This matters beyond Haskell specifically. It's a data point in the broader industry shift toward languages where the type system does more work — TypeScript's growth, Rust's adoption, Kotlin's displacement of Java. Mercury represents the far end of that spectrum.
### The scale problem is real but solvable
Two million lines of any language creates build and tooling challenges. Two million lines of Haskell creates specific ones. GHC (the Glasgow Haskell Compiler) was not originally designed for codebases this size, and compile times are the most visible pain point.
Mercury invested significant engineering effort into build infrastructure — not because Haskell is broken at scale, but because any serious codebase at this size requires build engineering, and Haskell's toolchain needed more custom work than, say, Go's or Java's would. This included optimizing incremental compilation, managing module dependency graphs, and building internal tooling to keep developer feedback loops fast.
The honest read here is that Haskell at 2M lines requires a team that's willing to treat build infrastructure as a first-class engineering problem. If your team treats the build system as someone else's problem, Haskell at this scale will punish you. If you invest in it — as Mercury clearly has — the compiler becomes an asset, not a bottleneck.
### The hiring question cuts both ways
Every Haskell discussion eventually arrives at hiring. The pool is smaller. This is an undeniable fact. Mercury's position — and it's one shared by other Haskell shops like Standard Chartered, Serokell, and Well-Typed — is that the smaller pool is offset by signal quality. Engineers who learn Haskell tend to be self-motivated, deeply technical, and comfortable with abstraction. The language acts as a filter.
This argument has limits. A team of 15 brilliant Haskell engineers may outperform a team of 30 average Java engineers on code quality, but if you need to hire 50 people in a year, the math gets hard. Mercury has navigated this by being a well-funded, high-profile employer in the Haskell ecosystem — they can attract the available talent. A less visible company might not have that luxury.
The practical takeaway for engineering leaders: Haskell is viable for teams that prioritize depth over breadth in hiring, operate in domains where correctness is non-negotiable, and are willing to invest in onboarding engineers who may know typed FP concepts but not Haskell specifically.
### If you're considering Haskell
Mercury's post is the strongest public case for Haskell in production since Facebook's Sigma papers. But context matters. Mercury chose Haskell early, when the codebase was small and the founding team had deep Haskell experience. Migrating an existing 500K-line Python or Java codebase to Haskell is a different proposition entirely — and not one Mercury's experience validates.
If you're starting a new project in a high-correctness domain (fintech, healthcare, infrastructure), Mercury's experience suggests Haskell is a defensible choice, provided your founding engineers are fluent and your organization is willing to invest in tooling. If you're looking to rewrite an existing system, look at Rust or Kotlin instead — they offer stronger type systems than your current stack without the ecosystem and hiring cliff.
### If you're in a different typed FP language
The broader lesson applies to anyone using OCaml, F#, Scala, or even TypeScript with strict settings. The value of Mercury's post isn't "use Haskell" — it's that investing in type-level correctness for financial logic pays compound returns at scale, regardless of the specific language. If you're writing financial software in TypeScript, Mercury's approach to encoding business invariants in types is directly applicable through branded types, discriminated unions, and strict null checks.
### For the "just use Go/Python" crowd
Mercury's post doesn't invalidate simpler language choices for simpler domains. A CRUD API that proxies to a third-party service doesn't need dependent types. But it does weaken the blanket claim that functional programming languages can't handle real-world engineering at scale. Two million lines of Haskell processing billions of dollars in a regulated industry is not a toy project or a conference talk.
Mercury's willingness to publish this level of detail is itself significant. The Haskell ecosystem has long suffered from a perception gap: plenty of companies use it, but few talk publicly about the operational reality. Posts like this shift the Overton window for language choice conversations in engineering orgs. Whether Mercury's codebase grows to 5 million lines or they eventually hit a wall that forces a partial rewrite, the current data point stands: Haskell works at scale, in production, in a domain where bugs have dollar signs attached. The question was never really whether it *could* work — it was whether anyone would invest enough to prove it.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.