Enterprise Haskell at H-E-B | The Haskell Programming Language's blog

Enterprise Haskell at H-E-B

Joshua Miller July 16, 2026 [Haskellers from the trenches] #Production #H-E-B

This article is the second installment of our series "Haskellers from the trenches",<br>where we invite experienced engineers to talk about their subjects of expertise, best practices, and production tales with Haskell

The mainframe problem

When I joined H-E-B back in 2018, I was entering a world far removed from any<br>of my previous roles in technology. H-E-B is a retail company first, and the<br>largest privately held company in Texas. Our customers care about full shelves,<br>not the systems behind them, and for decades those systems delivered:<br>rock-solid COBOL mainframes doing their job reliably, day in and day out.<br>Reliability like that is no small thing. But customer expectations have<br>shifted. Curbside pickup, home delivery, real-time inventory, in-store search,<br>and many other tech-heavy features have really only emerged in the last 10<br>years, and meeting that demand means scaling supply chain operations across<br>435+ stores and the distribution centers that feed them. That kind of growth<br>asks more of our core systems than they were originally designed to give,<br>especially as the grocery business turns more digital and more competitive by<br>the year.

It's no secret that a lot of the world still runs on mainframes. There's<br>usually little incentive to spend the capital on a massive lift-and-shift into<br>the cloud when current systems maintain the status quo well enough. Copying<br>code from one machine to another is hardly the real challenge here. Usually<br>these kinds of projects fail to deliver because they lack the bespoke<br>institutional knowledge encoded in decades of legacy business logic. How do you<br>take a monolithic application operating on hundreds of tables and split it out<br>into microservices, owned and operated by their own autonomous engineering<br>teams? It's both a technological and political undertaking of enormous<br>proportions, and an expensive one. Whatever product comes out on the other end,<br>you can bet that the business owners don't want to repeat this process ever<br>again.

Enter the lambda

Haskell was originally pitched by consultants as the lingua franca for a new<br>initiative to replace the largest mainframe application in the company. I came<br>onto this new project in its infancy, ready and giddy to use Haskell on a<br>real-world project with real-world impact. What started as an experiment grew<br>into multiple production systems now running critical supply chain<br>applications. Eight years on, those systems are still in production, with<br>nearly a million lines of Haskell maintained by several teams across different<br>domains. So there have been real successes, but also real struggles. I hope that<br>my experience on these projects can translate into some valuable lessons for<br>those who wonder about or may already be running Haskell programs in<br>production.

Why Haskell?

Pitching a programming language as a business solution is an uphill battle.<br>Haskell is not known for being an enterprise language, and while it thrives in<br>programming-language research, it lost the foothold it once had in the intro<br>course, despite Dijkstra's famous defense of it over Java in his letter to the<br>UT Austin Budget<br>Council.<br>But "enterprise language" says more about market forces than language design.<br>The same momentum that filled the intro course with Java fills the hiring pool<br>and the vendor SDK lists, and nearly all of that momentum belongs to imperative<br>languages, deemed easier to hire for, and these days, easier to prompt for. The<br>enterprise cares not for laziness, pure functions, immutable data, or anything<br>that weighs lambda calculus against object-oriented orthodoxy. The enterprise<br>just wants another COBOL: a system that runs for 40 more years without<br>null-pointer exceptions and with a lower maintenance burden. I firmly believe<br>that Haskell fits into this niche. But it's not trivial to translate the<br>benefits of a souped-up polymorphic lambda calculus and software-transactional<br>memory into a business case.

So what's my pitch?

I can tell our CTO that a Haskell application will suffer fewer classes of<br>runtime failure by default, ruling out the whole category of bugs that<br>imperative and dynamically typed programs encounter on a daily basis. There<br>will still be bugs, but the ones that remain tend to be the interesting ones in<br>our business logic, rather than null-pointer exceptions and type confusion.

In the face of multi-year strangler fig migrations of legacy systems, I can<br>tell Haskell developers that it's ok to make mistakes. They can iterate<br>while the business requirements are still taking shape, because GHC gives<br>them the tools for painless refactoring. That freedom is what lets a<br>migration run like an agile project instead of a waterfall. The business<br>measures results incrementally, rather than paying up front for an incorrect,<br>crystallized product that will...