▶ YouTube Summaries

• https://www.youtube.com/watch?v=zZ5-KVDIaPg
• Original title: Haskell is DONE

ThePrimeagen reacts to Avi Press's blog post "After 7 years in production, Scarf has reluctantly moved away from Haskell." What makes the article compelling is the author's credentials: a 16-year Haskell devotee who founded a successful Haskell company and serves on the Haskell Foundation and haskell.org committees, yet is now leaving the language he loves. The core reason is not the language itself but compilation and ecosystem friction — a cold build can take 15 minutes, which becomes crippling when running many coding agents in parallel. The AI era added a "third place" to catch errors (code-generation time), which devalues Haskell's slow-but-thorough compile-time type checking. The two big surprises for Prime: a Haskeller admitting types are worth less when type-checking is slow, and the team migrating new API work not to Rust but to Python. He closes predicting that after cost, raw speed of iteration will be the next major battleground for coding tools in 2026.

Why this article matters

Scarf is one of the few real production Haskell shops, and the author (Avi Press) is a genuine Haskell insider and enthusiast — not a hater. Prime respects when someone deeply invested in a technology chooses to leave, because the reasoning is worth learning from (he draws a parallel to his own recent "done with Go" video). He frames Haskell as the "white paper language" that nonetheless has this notable production case.

Compilation and ecosystem friction is the real culprit

The problem is not Haskell-the-language but tooling. Companies must build their own bespoke caching, dev environments, and CI because the ecosystem doesn't provide them. This was livable for years — until AI changed the trade-offs.

AI introduces a third place to catch errors

Historically errors are caught at compile time or run time; now there's "code generation time" — the model avoids mistakes before the compiler sees the code. As models improve, the relative value of exhaustive compile-time checking drops. Prime is surprised a Haskeller would say type safety isn't worthless but that the cost of type checking now matters more. A 15-minute cold build means every new agent work-tree pays a 15-minute setup tax; run many agents in parallel and CPU contention pushes that to 30–40 minutes, while an LLM might generate the code in ~2 minutes — the build becomes the bottleneck. Prime contrasts this with his own ~20,000-line Odin project that rebuilds in 70–100 ms.

The plot twist: they moved to Python, not Rust

Prime expected a Haskell team chasing a fast loop to pick Rust (strong compiler, similar rich types). Instead, Scarf started all new API work in Python — a language Haskell "type Andys" would normally look down on. He calls it an "M. Night Shyamalan turnaround" and evidence that AI is upending cultural norms in programming.

The productivity payoff and the honest engineer

Prime praises the author for refusing single-metric claims: PR throughput didn't obviously rise, commit volume is noisy, lines of code is a bad proxy. The real change is in the shape of what can now ship — high-effort work with minimal oversight, and some fixes going from customer call to filed ticket to reviewed, merged, deployed, and live before the call even ends. Prime agrees simple bug fixes can go largely autonomous with good evals/review.

Prediction: speed becomes the next focus

Prime lays out the cost/speed/correctness triangle. Correctness dominated the last few years (he cites "Fable" as accurate but slow and expensive). His prior prediction — cost mattering more — is playing out (new Grok model is fast and cheap; a new "Soul" model ~20x cheaper than old Fable at similar correctness). His next prediction for the rest of 2026: raw speed will take center stage, because fast iteration (e.g., getting three implementations back in 3 minutes) is worth paying a premium for.