By ByteBot
Avi Press chairs the Haskell Foundation board — the organization tasked with keeping Haskell alive and relevant. He also just moved Scarf’s production backend off Haskell after seven years. Not because the language failed him. Because AI coding agents made slow compilation economically unbearable. That tension, laid out in a post he published yesterday, is now generating hundreds of comments on Hacker News and real discomfort on the Haskell community forums.
This is not an outsider dunking on a language they never understood. It is the person most invested in Haskell’s future telling you he cannot justify using it anymore.
Compile Times Were Always Slow. AI Made That Unacceptable.
Haskell’s compilation speed has been a known friction point for years. Developers accepted it because the type system caught entire classes of bugs before they reached production, and long-running codebases were kept warm in CI caches anyway.
AI-assisted development broke that calculus.
When a coding agent can generate a working implementation in minutes, the bottleneck shifts to whatever happens next. For Python: nothing. For Haskell: a cold build that can run 15 minutes or more. Press described the problem directly in his post: “If an LLM can produce a working implementation in a few minutes, but your compile step takes much longer, compilation is now the bottleneck.”
The compounding effect is what makes this bad. Modern AI-assisted workflows spawn multiple parallel branches simultaneously — different agents exploring different approaches, all needing to compile. One slow build is a nuisance. Ten parallel slow builds across ten agent branches is a development process that barely moves. Every shared Nix cache setup and incremental build optimization Press’s team tried ran into the same ceiling.
What Scarf Actually Did
The migration was not a big-bang rewrite, which is the right call. Scarf started doing all new API work in Python, stood up a Python server next to the existing Haskell service, and routed traffic gradually. LLMs helped with the porting. The Haskell service keeps running where it was not yet replaced.
Practical and undramatic. The kind of migration that actually works.
Python was the destination, not Rust or OCaml — a choice some commenters found surprising given Python’s dynamic typing, but one Press does not seem particularly anguished about. Python’s LLM generation quality is better simply because of training data volume. More Python exists on the internet, so models are better at writing it. That is a feedback loop that compounds.
The Counterarguments Are Real
The Haskell community is not rolling over. Some pushback is worth taking seriously.
A developer at a financial exchange pushed back on the core thesis: “LLMs + Haskell is an extremely productive combo.” The argument is that Haskell’s type system acts as a guardrail for LLM output — the compiler rejects incorrect agent-generated code immediately, forcing convergence on correct solutions faster than Python’s runtime-discovered failures allow. One commenter cited a 17-hour ML training pipeline that failed due to a dynamic typing error, something a real type system would have caught at build time.
There is also a technical counterargument about the root cause. Haskell community members pointed out that one of the libraries Scarf used — Beam, an ORM known in the community for painful compile times — may have been the actual culprit, not GHC itself. One developer cited a 1.2-million-line Haskell codebase compiling in under three minutes, suggesting the slow builds are solvable with the right architecture, not fundamental to the language.
The proposed middle ground from commenters: OCaml for fast compilation without sacrificing type safety; Go for simplicity and sub-second builds; TypeScript for a typed-enough Python alternative.
The Warning Is Bigger Than One Company
Press closes his post not with “Haskell is dead” but with something harder to dismiss: a warning to the Haskell Foundation about opportunity cost.
The community is focused on dependent types, advanced type theory, and academic correctness. Press argues it should be focused on build speed, better documentation for LLMs, and agent-optimized workflows. “The opportunity cost of this stagnation has never been higher,” he writes.
That is a narrow window closing. Languages that want to thrive in the AI-assisted development era need fast feedback loops, large training corpora, and tooling that plays well with agents. Python, Go, and TypeScript have all three. Haskell has none of them in useful quantity.
What This Means for Your Stack
If you are currently in Haskell and it is working — keep going. Scarf’s experience is not universal, and the counterarguments about type-system-driven LLM convergence are legitimate.
If you are evaluating languages for a new project that will rely heavily on AI-assisted development, compile-time overhead is now a real factor on your checklist. It was not two years ago.
And if you care about Haskell’s long-term viability: the person who chairs its foundation board just told you what the language needs to survive. That is worth paying attention to.
