Mercury's blog post details their experience running ~2 million lines of Haskell in production banking, handling billions in deposits under full US regulatory compliance. They present this as evidence that Haskell works not just for small teams or compilers, but for large-scale, high-stakes financial infrastructure.
The post is notable for its candor about the engineering realities of scaling Haskell across a growing organization. Mercury describes how compile times become a developer experience problem, hiring requires building a pipeline for a less common language, and onboarding engineers under banking compliance deadlines is fundamentally different from teaching Haskell to enthusiasts.
The editorial argues that Mercury's post is significant precisely because it moves past the two-decade-old 'but does Haskell work in production?' question. Instead, it addresses the organizational scaling dimension — how a growing team ships features in an unfamiliar language under real deadlines and compliance pressure, which is the question the Haskell community has lacked large-scale evidence for.
Mercury, the fintech company offering banking services to startups and e-commerce businesses, published a detailed engineering blog post on blog.haskell.org describing their experience running what may be one of the largest commercial Haskell codebases in the world — approximately two million lines of Haskell code in production.
This isn't a toy project or a compiler. Mercury handles real money: billions of dollars in deposits, thousands of business customers, and the full regulatory weight of the US banking system bearing down on every line of code. Their codebase has grown to roughly 2 million lines of Haskell, making it one of the largest known production Haskell deployments outside of Meta's spam-filtering infrastructure (Sigma) and the financial trading firms that tend to stay quiet about their stacks.
The post landed on Hacker News and immediately drew attention — not because "company uses Haskell" is novel, but because the scale and candor are. Most Haskell-in-production posts describe small teams with modest codebases. Mercury's post talks about the engineering reality of scaling a Haskell codebase across a growing organization with real deadlines and real compliance requirements.
The Haskell community has spent two decades answering the question "but does it work in production?" with small-to-medium case studies. Mercury's post changes the conversation because it addresses the *organizational* scaling question, not just the technical one.
The hardest problems at 2 million lines aren't language problems — they're people problems, tooling problems, and build-system problems. Compile times become a developer experience issue. Hiring becomes a pipeline challenge. Onboarding new engineers to an unfamiliar language while shipping features on a banking compliance timeline is a fundamentally different challenge than teaching Haskell to enthusiasts.
Mercury's experience is particularly instructive because banking software is one of the domains where strong static typing should, in theory, pay its highest dividends. Financial calculations that must be correct. State machines governing account lifecycles that must be exhaustive. API contracts with partner banks that must be precisely modeled. The type system isn't an academic luxury here — it's a regulatory necessity dressed in different clothes.
What makes this post valuable compared to the typical Haskell advocacy is the willingness to discuss where things are hard. GHC compile times at scale are a known pain point, and any team approaching seven figures of lines of code will feel it. The Haskell tooling ecosystem — while vastly improved in recent years with HLS (Haskell Language Server) and better Cabal/Stack integration — still has gaps compared to the Go or Rust developer experience. Mercury's engineering team has had to build internal tooling to fill those gaps, which is both a testament to their commitment and a honest signal about the ecosystem's maturity.
The hiring question deserves its own paragraph. The conventional wisdom is that Haskell companies can't hire. Mercury's counter-argument is more nuanced: the hiring pool is smaller, but the signal-to-noise ratio is extraordinary. Engineers who know Haskell (or are motivated to learn it) tend to be deeply thoughtful about software correctness and abstractions. In a banking context, that self-selection bias is a feature, not a bug. The tradeoff is real — you won't fill a role in two weeks — but the quality-adjusted hiring outcome may be superior.
If you're evaluating whether a typed functional language can work for your team, Mercury's experience offers several concrete lessons.
First, the type system ROI scales superlinearly with domain complexity. Banking, healthcare, infrastructure — domains where incorrect behavior has outsized consequences — are where Haskell's type system earns back its learning-curve investment. If you're building a CRUD app, the overhead probably isn't justified. If you're modeling complex state machines with regulatory constraints, the types do real work.
Second, commit to the ecosystem or don't bother. A half-hearted Haskell adoption — one service, staffed by one enthusiast — will fail. Mercury's success comes from making Haskell the default, investing in internal tooling, and building hiring pipelines around it. The language choice is a strategic bet, not a per-project decision.
Third, compile times are the real tax. At scale, GHC's compilation model becomes the dominant developer experience concern. Teams approaching this scale should invest early in modularization, build caching (via Nix or similar), and potentially GHC's recent work on incremental compilation. This isn't unique to Haskell — Rust and C++ teams face similar walls — but it's the most commonly cited friction point.
For teams currently on TypeScript, Go, or Java considering a move toward stronger typing: Haskell isn't the only option. Rust, OCaml, F#, and even TypeScript with strict configurations offer points on the spectrum. But Mercury's post demonstrates that Haskell specifically can work at a scale that most skeptics assumed it couldn't.
Mercury's 2-million-line codebase is probably the strongest datapoint the Haskell ecosystem has ever produced for enterprise adoption. It won't settle the debates — nothing will — but it shifts the burden of proof. The question is no longer "can Haskell work in production?" It's "under what conditions does it make sense to choose it?" For Mercury, handling other people's money in a compliance-heavy environment, the answer appears to be: conditions exactly like these. The Haskell community should study this case not for validation, but for the specific engineering investments that made it work.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.