Scrolls
12 min read
On this page

Why Haskell?

Haskell has a reputation. Depending on who you ask, it's either the language that finally taught them how to think about software, or the language that snubbed them with a Monad tutorial in week one. Both reactions are reasonable. Haskell is a bet on a small set of ideas — purity, laziness, strong static types — taken much further than any mainstream language has dared. The payoff, when it lands, is code that does what its type says and very little else.

This is not a language you reach for because it's faster to ship a CRUD app. You reach for it because correctness is expensive, refactors are painful, or you're tired of runtime surprises in code that compiled clean.

What Makes Haskell Different

There are roughly four things working together. Pull any one of them out and you don't have Haskell anymore — you have a different language with one nice feature.

Purity. A Haskell function with type Int -> Int cannot read a file, log a message, or mutate a database. The type system enforces this. If you want effects, you need a type that says so, like IO Int or State s Int. This sounds restrictive, and at first it is. Then you notice that 80% of the bugs you used to write came from a function quietly doing something its name didn't suggest.

Laziness by default. Expressions don't evaluate until something demands their result. You can write take 10 (filter prime [1..]) and it terminates, because the infinite list is consumed only as far as needed. This is a sharp edge — laziness causes its own bugs, especially around space leaks — but it also enables a different style of decomposition where producers and consumers compose without intermediate collections.

A type system that earns its keep. Hindley-Milner inference means you rarely have to write types, but the compiler always knows them. Algebraic data types, typeclasses, and parametric polymorphism let you encode invariants the compiler then enforces. When people say "if it compiles it works," they're exaggerating, but only somewhat — a lot of bug categories that plague Java or Python codebases are simply impossible to express in Haskell.

Higher-kinded everything. Haskell lets you abstract over things that other languages can't. Functor, Applicative, Monad, Traversable — these aren't libraries, they're abstractions over the shape of computation itself. Once you internalize them, code in other languages starts to look like it's repeating itself for no reason.

-- a function that can't lie about what it does
double :: Int -> Int
double x = x * 2

-- a function that does IO must say so in its type
greet :: String -> IO ()
greet name = putStrLn ("Hello, " ++ name)

-- the compiler will refuse to let you call greet
-- from inside double — they live in different worlds

A small concrete example of the abstraction power. This function works on any Functor — lists, Maybe, IO, trees, futures, any container or context that supports mapping:

shiftBy :: (Functor f, Num a) => a -> f a -> f a
shiftBy n = fmap (+ n)

-- works on a list:
ghci> shiftBy 10 [1, 2, 3]
[11, 12, 13]

-- works on a Maybe:
ghci> shiftBy 10 (Just 5)
Just 15

-- works on a pair (the second component):
ghci> shiftBy 10 ("score", 50)
("score", 60)

In most languages, you'd write three different functions or generate code with macros. In Haskell, the type system carries the abstraction.

Who Actually Ships Haskell

The "Haskell isn't used in industry" myth refuses to die, but the list of serious production users is long enough at this point that it's worth dragging out.

Facebook's Sigma is an anti-spam and anti-abuse system that processes every interaction on the platform — every message, comment, friend request — and decides whether to allow it. The DSL that expresses these rules is Haskell, and the engine that evaluates them was rewritten from FXL (an internal language) to Haskell because of how easy it was to refactor. Sigma evaluates somewhere on the order of a million requests per second. The Haxl library, which Facebook open-sourced from this work, batches and caches data fetches automatically based on the structure of the computation.

Standard Chartered has been writing Haskell in production for over a decade, primarily in their financial markets division. They use a fork of GHC called Mu and have tens of millions of lines of Haskell powering pricing, risk, and trading systems. The argument is straightforward: when a bug costs millions of dollars, paying upfront for a language that catches more bugs at compile time is cheap.

Mercury runs their banking platform on Haskell. The CTO has been public about why — not because Haskell is cool, but because it makes refactoring safe in a domain where bugs touch real money. They have hundreds of thousands of lines in production and have been hiring Haskell engineers consistently.

IOG (formerly IOHK) built Cardano, a proof-of-stake blockchain, in Haskell. The reasoning was that a system handling billions of dollars of value needs a language that supports formal verification and equational reasoning. Plutus, Cardano's smart contract platform, is itself a Haskell-derived language.

Galois uses Haskell for high-assurance work — they build tools for the US government and DARPA in domains like cryptography, formal methods, and verified compilers. When the customer is the NSA or a defense contractor, "the type system caught it" is a legitimate engineering argument.

Tweag is a consultancy that does a lot of Haskell work, including for biotech and pharma companies where reproducible scientific computing matters.

Smaller but notable: GitHub uses Haskell for Semantic, their code analysis library. Hasura built their GraphQL engine in Haskell. Awake Security (now part of Arista) used it for network threat detection. Channable, Flipstone, Obsidian Systems, Serokell — there are hundreds of companies, just not many household names outside finance and crypto.

A Taste of the Code

Before going deeper, here's a small program that hints at the texture of real Haskell. We'll parse a list of CSV-ish records into a typed structure, validate them, and report what failed.

import Data.List (intercalate)

data Person = Person
    { personName :: String
    , personAge  :: Int
    } deriving Show

data ParseError
    = WrongFieldCount Int
    | NotANumber String
    deriving Show

parseRow :: String -> Either ParseError Person
parseRow row = case splitComma row of
    [name, ageStr] -> case readMaybe ageStr of
        Just age -> Right (Person name age)
        Nothing  -> Left (NotANumber ageStr)
    fields         -> Left (WrongFieldCount (length fields))

parseAll :: [String] -> ([ParseError], [Person])
parseAll = partitionEithers . map parseRow

A few things to notice. Either ParseError Person is in the type — the function tells callers it can fail and how. The ParseError type enumerates the failure modes; if we add a third, the compiler will tell us every place that needs an update. parseAll separates the failures from the successes in one pass without losing either. None of this is fancy by Haskell standards; it's just what idiomatic code looks like.

What Haskell Teaches You

Even if you never ship Haskell professionally, learning it changes how you write code in every other language.

You stop reaching for mutable variables when you don't need them. You realize that a lot of "loops" are really folds, maps, or filters in disguise, and saying so makes the intent obvious. You start thinking about types as a design tool instead of an annotation chore — the shape of your data drives the shape of your functions, not the other way around. You become allergic to functions whose signatures lie about what they do.

The functional patterns from Haskell — Option/Maybe, Result/Either, immutable data, pattern matching — have leaked into Rust, Swift, Kotlin, Scala, and modern TypeScript. Once you've used them in their natural habitat, you can spot the cargo-cult versions and the genuinely useful adaptations. Rust's Result is essentially Either with different names. Swift's optionals are Maybe. The lineage is direct.

The other big transferable lesson is equational reasoning — the ability to substitute equals for equals because functions are pure. Once you've experienced refactoring where you can replace a call with its body and know nothing else changes, you'll feel the absence of this property in every imperative language you touch afterwards.

There's also a class of insight that's harder to name. Working in Haskell teaches you to distinguish data from operations, structure from policy, and intent from implementation in ways that other languages let you blur. You start writing better code in Python because Python can be written carefully — Haskell shows you what "carefully" looks like. Several engineers I've worked with say their Python or Go got noticeably better after a few months of Haskell, even when they had no plans to keep using it.

When Haskell Is the Right Choice

Haskell is a good fit when correctness is more expensive than developer ramp-up time. Finance, where a bug is measured in dollars. Compilers and language tooling, where the domain is naturally tree-shaped and pure. Cryptocurrency and blockchain, where the code is the contract. Domain-specific languages, parsers, formal verification, scientific computing where reproducibility is critical.

It's also good when you're building a system that will live for ten years and be modified by people who haven't been hired yet. The type system carries documentation and enforces invariants that comments can't.

Concrete examples of where Haskell fits well:

  • A pricing engine that has to model fifty different financial products with overlapping rules and constraints. ADTs and pattern matching keep the logic legible across the whole catalog.
  • A compiler or interpreter for a domain-specific language. Trees of expressions, recursive evaluators, and traversal patterns are exactly what Haskell was designed for.
  • A spam or fraud rule engine like Facebook's Sigma. The rules are pure functions, the engine batches and caches data fetches, and the type system keeps the evolving rule set consistent.
  • A blockchain or smart contract platform. Plutus is itself written in and compiles to Haskell-derived intermediate languages.

How a Real Codebase Looks

If you peek at a serious Haskell project — say, the Cardano node, or Hasura's GraphQL engine — the code at the leaf level looks deceptively ordinary. Functions are short. Types are explicit. Modules are small. The complexity lives in the type structure, not in clever code.

-- a snippet in the style of a real production type
data ApiResponse a
    = Success a
    | ClientError Int String     -- 4xx
    | ServerError Int String     -- 5xx
    | NetworkError IOException
    deriving (Show, Functor)

handleResponse :: ApiResponse User -> IO ()
handleResponse = \case
    Success user        -> logUser user
    ClientError 404 _   -> reportMissing
    ClientError code msg -> reportClientError code msg
    ServerError code msg -> retry code msg
    NetworkError ex     -> retryWithBackoff ex

Notice the \case (lambda case) for compact pattern matching, the deriving Functor for free, the explicit handling of every failure mode. None of this is exotic; it's just everyday Haskell. The compiler checks that you handle every constructor; if someone adds a RateLimitError next year, your build will tell you to update this function.

That's the mental shift the language asks for, and the payoff: code that documents itself and refuses to ignore the cases that bite you in other languages.

When It Isn't

Haskell is a poor fit for problems that are mostly glue — calling APIs, transforming JSON, hitting databases — where the language doesn't add much and the ecosystem is thinner than Python or Node. You can do it, but you'll spend time reinventing things that come for free elsewhere.

It's a poor fit when you need to hire fast. The talent pool is small. The people in it are usually excellent, but there are not many of them, and they tend to cost money.

It's a poor fit for hot loops where every cycle counts. GHC produces solid code, but laziness adds overhead that's hard to predict, and the gap between idiomatic Haskell and hand-tuned Haskell is wider than in Rust or C++.

And it's a poor fit when your team isn't on board. Haskell rewards careful thinking, and a team that wants to ship features without thinking will be miserable. The language doesn't let you not think.

Common Pitfalls

Treating it like a typed Python. Haskell isn't a scripting language with types bolted on. The whole design assumes you'll structure your program around types. People who try to write imperative code in Haskell write bad Haskell.

Chasing every abstraction. The type system invites tower-building. You can write code that uses three monad transformers, two type families, and a lens combinator where a plain function would do. Resist. Idiomatic Haskell is often simpler than people expect.

Underestimating the learning curve. It's real. Plan for two to three months of feeling slow. The curve is front-loaded — once you're past it, productivity is high.

Believing the "if it compiles it works" line literally. It compiles, therefore the types are consistent. Logic bugs still exist. Performance bugs still exist. Laziness bugs definitely still exist.

Comparing Haskell jobs to total programming jobs and concluding the language is "dead." The talent pool is small but the demand for it is roughly proportional. Companies that want Haskell engineers are competing for the same handful of people, and rates reflect that. If your goal is interesting work in finance, crypto, or specialized tooling, the market is small but functional.

Using String everywhere because that's the default. Real Haskell projects use Text or ByteString for almost everything. The String type is a linked list of characters and it's slow. New learners often miss this and produce slow code, then conclude the language is slow.

What the Learning Curve Actually Looks Like

A rough timeline based on what most people experience:

Week 1-2. Syntax feels strange. Pattern matching clicks fast. Types feel like extra work. You write everything as if it were Python with weird brackets and wonder why people make a fuss.

Week 3-6. ADTs and pattern matching become second nature. You start designing with types first. The error messages, which seemed cryptic, start making sense. You discover GHCi and stop running standalone executables.

Month 2-4. Functor and Monad finally click — usually after the seventh tutorial fails to explain them in a way that lands. You realize they're abstractions over patterns you've been writing all along, not new concepts. You start composing with <$>, <*>, and >>=.

Month 4-6. You begin to read other people's Haskell. Lens, mtl, conduit — libraries that looked impenetrable now have a shape. You write a real project and ship something.

Year 1+. You hit space leaks, type-level programming, and the parts of GHC that are genuinely advanced. You learn to profile, add bang patterns, and understand when laziness helps and when it bites. You become useful in production.

The curve is real and it's front-loaded. The good news is that almost everyone follows roughly this trajectory; the bad news is that the early weeks are uncomfortable. Companies hiring Haskell engineers — Mercury, Standard Chartered, IOG — typically expect a multi-month ramp even for experienced functional programmers from other languages.

Key Takeaways

Haskell is a bet on purity, laziness, and strong static types as the foundation of software, taken further than any mainstream language. It's used in production at Facebook, Standard Chartered, Mercury, IOG, Galois, Tweag, and many others — usually in domains where correctness is expensive. It teaches you to think about types as a design tool, to treat functions as values, and to reason about code by substitution. It's the right choice when bugs are costly and developers will be modifying the code for years; it's the wrong choice when speed-to-market or hiring volume is the constraint.