[le-mark]

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?

[imoverclocked]

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.

[troupo]

> 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

Given that tracing etc. is IO, are they just threading IO through the entirety of all their Haskell code?

[tome]

Tracing doesn’t actually require IO, only emitting the traces does, and those two need not be done at the same point.

In any case, anywhere they’re doing HTTP calls they are already threading IO, so they don’t have to pay an additional cost.

[verandaguy]

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.

[appplication]

Agree on the 2M lines of code point. Looking at GitHub stats, I’ve personally written about 500k loc over the last 6 years, and that’s not including my teammates contributions etc. There are a lot o f things on our roadmap and I would consider the codebase to still be immature a feature incomplete. And this is all for a particular niche in a gigacorp.

If anything, having your entire company’s codebase be 2M loc and it be a functional product seems reasonably efficient to me.

[reikonomusha]

Haskell is typically terse in addition to expressive. So "tight" seems more apt.

Lisp is traditionally not so terse, but still expressive.

[LeCompteSftware]

I obviously don't know what the codebase looks like, but

a) Haskell's reputation for terseness partially comes from its overrepresentation in academic / category-theoretic circles, where it's typically fine to say things like `St M -> C T`. But for real software it's a lot more useful to say things like `TransactionState Debit -> Verified Transaction` etc etc.

b) The other part of Haskell's terse reputation is cultural, something extending back to LISP: people being way too clever about saving lines with inscrutable tricks or macros. I imagine that stuff is discouraged at a finance company like Mercury in favor of clarity and readability: e.g. perhaps the linter makes you split monadic stuff into pedantic multiline do expressions even if you can do it in a one-liner with >> and >>=.

[gf000]

> Haskell is “tight”

Absolutely not an objective metric, but I have found that Haskell just has a different "aspect ratio". Line count may be somewhat lower, but the word count is essentially largely the same as more imperative OOP languages.