A couple million lines of Haskell: Production engineering at Mercury

Post by cubefox » Sun, May 03, 2026, 5:10 PM UTC

matt-noonan wrote: post #158

cubefox wrote: post #37

I know this is not the point of the article, but I find the anecdote in the beginning about null pointer errors somewhat ironic. Haskell's solution to null pointers are option types (`Maybe x` in Haskell), but these are known to be suboptimal. In languages with option types, if you want to weaken the type requirement for a function parameter, or strengthen the guarantee for a return type, you have to change the code…

This is really a non-issue in practice. In the olden days, you’d just make the change and then spend a pleasant hour or two fixing the callsites by responding to compiler errors in a pretty low-thought, mechanistic way. Nowadays you can outsource that part to a coding agent and get on with your life. In any case, the fact that the compiler knows what code needs to be updated is a real superpower.

Post by reikonomusha » Sun, May 03, 2026, 5:26 PM UTC

verandaguy wrote: post #11

le-mark wrote: post #6

It’s hard to imagine what two millions lines of Haskell could possibly be doing. I mean that’s a lot of code and I have the impression that Haskell is “tight” meaning a little code can do a lot. Maybe they have a lot of libraries to do things like json serializing/deserializing, rest api frameworks, logging etc?

Nit: the quality of a language that you call "tight" is usually called "expressive." You can use few characters to express a relatively very abstract idea. Some people call this "high-level," too. I will say, though, that 2 million lines of code is much less code than it sounds like at first glance, especially for a company in a highly-regulated space like finance, plus a few years of progress.

Post by [deleted] » Sun, May 03, 2026, 5:41 PM UTC

cubefox wrote: post #181

matt-noonan wrote: post #158

Earlier quoted context omitted.

This is really a non-issue in practice. In the olden days, you’d just make the change and then spend a pleasant hour or two fixing the callsites by responding to compiler errors in a pretty low-thought, mechanistic way. Nowadays you can outsource that part to a coding agent and get on with your life. In any case, the fact that the compiler knows what code needs to be updated is a real superpower.

Well, it's still a suboptimal solution. Moreover, if you are modifying any library functions, there is a high probability that you can't change the call sites at all because you simply don't have access to them.

Post by kylebshr » Sun, May 03, 2026, 5:49 PM UTC

LoganDark wrote: post #91

sillysaurusx wrote: post #30

I just wanted to leave a glowing comment about Mercury itself, since this is one of the few times I’ll be able to. I’ve been using Mercury for 5 years. In that time, I’ve been able to wire transfer money without having to worry it might disappear (functionally impossible at certain other banks), created hundreds of virtual debit cards each with their own limit and pulling from different accounts, created dozens of ac…

I badly want to try out Mercury, in fact I have an account already, but they don't yet support Zelle. I really hope their national bank charter application gets approved. (They applied for one last December.) Once they support Zelle, I'll drop U.S. Bank, as their app sucks and they don't have an API.

Post by thrawa8387336 » Sun, May 03, 2026, 5:57 PM UTC

uecker wrote: post #106

k_bx wrote: post #100

Earlier quoted context omitted.

What you cannot do is compile-time safety guarantees, and in languages like Rust type system isn't strong enough to do some advanced compile-time guarantees (via types). So no, you cannot do this in basically any language (unless you turn it into Haskell).

What the parents describe can be done with almost any language.