A Couple Million Lines of Haskell: Production Engineering at Mercury

This isn't specific to Rust or Typescript. You can do this in basically any language.

Imagine you have to distinguish between unescaped and escaped strings for security purposes. Even with a dynamically typed language, you can keep escaped strings as an Escaped class, with escape(str)->Escaped and dangerouslyAssumeEscaped(str)->Escaped functions (or static methods). There's a performance cost to this, so that's a tradeoff you have to weigh, but it is possible.

Another way of doing this is Application Hungarian[1], though that relies on the programmer more than it does on the compiler.

[1] https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

I have noticed that everything in their app Just Works. It's very satisfying coming from other services!

I'd also wager that hiring generalists with no prior experience in the language actually helped them, because they got to instill their culture and style from the ground up with their new hires. Pre vibe-coding, most of those people would'nt have wanted to just jump in and hack away with zero instruction.

From TFA:

> The problem is that we cannot trust code we cannot instrument. If a third-party binding makes HTTP calls through concrete functions, we have no way to add tracing, no way to inject timeouts tuned to our SLOs, no way to simulate partner outages in testing, and no way to explain the 400ms gap in a trace except by squinting at it and developing theories. So we write our own. More work upfront, but the clients we write are observable by construction, because we built them that way from the start.

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.

This happened to me.

I've made all my money over a decade in Haskell. Millions. Paid for all my stuff.

It all started with a recruiter on LinkedIn

As somebody who has helped hire many Haskell devs, I can say that lots of Haskell experience isn't always a positive. We have to filter carefully to make sure that we end up with developers who want to build real things, not developers who just want to get paid for noodling around with Haskell. As far as I'm concerned, I'd much rather hire somebody with lots of experience building things who ended up coming to Haskell later because they viscerally understand the benefits and risks. Somebody with lots and lots of Haskell experience who never delivered much is a big risk.

My fear with something like Haskell particularly and with hiring people who really love Haskell is that you risk ending up with a certain kind of personality who fetishizes the tool over the problem.

I've been this person, and I've worked with this kind of person, and been the victim of this kind of person. They love language X, or framework Y, and are convinced that so many problems in front of them are shaped in a way that would be solved through the application of it.

They now have a hammer and they go searching for nails to hit with it.

I've been in shops that used Haskell, and it was... fine? It's I guess nice for people who enjoy writing in it -- I prefer other FP languages personally. I like nerdy things like that and used to hang out on Lambda the Ultimate or whatever. But I don't think there's any real secret powers in Haskell or most other tools. I've been burned too many times by that kind of approach.

The irony of these fancy FP languages that were designed to develop compilers or to get PL academics off is that they're actually also really good at the most mundane code imaginable.

Being able to minimize boilerplate and have strong refactoring and bug resistant types is a huge edge.

The only problem is their ecosystems are limited so you might spend more time than you like implementing an API or binding a system library.

Without having run the whole company twice in parallel, once using Haskell and again in some other language, and without having measured both runs exactly the same way, I don't think metrics like you're interested in could possibly have sufficient context to mean anything reliable.

Obviously Mercury is successful, and obviously Haskell is how they did it. So it's essential to their success. Would it be instrumental to anyone else's anywhere else doing anything else? Can't possibly know, I don't think.

It's probably more likely it comes down to: if your programmers are capable of learning and working in Haskell, they're likely a cut above in terms of keenosity and nerdiness and motivation around programming, and you're likely to early-cull the people who just got into CS because mom and dad told them it paid well. That's likely to help produce better overall code health.