Scarf Drops Haskell After 7 Years - LLMs Changed the Calculus
TL;DR
Scarf moves from Haskell to Python after 7 years: why LLM-driven development made compile times a bottleneck, how the migration worked, and the HN debate.
Last updated: July 10, 2026
Avi Press, CEO of Scarf and a member of the Haskell Foundation board, published a post explaining why his company is moving away from Haskell after seven years of production use. The piece hit Hacker News with 161 points and 193 comments - and the discussion went exactly where you would expect when a prominent Haskell advocate says the language no longer fits their workflow.
The Core Argument#
Press spent 16 years as a Haskell advocate. Scarf ran successfully on Haskell with Servant, Beam, and PostgreSQL under contractual SLAs. This was not an emergency migration or a technical failure.
The breaking point was LLM-driven development.
His framing is blunt: "If an LLM can produce a working implementation in minutes, but your compile step takes dramatically longer, then your language has become a bottleneck."
The math changes when you shift from writing code yourself to orchestrating AI agents that write it. Agents need fast feedback loops and disposable execution contexts. Cold start times matter because you spin up fresh environments constantly. Caching strategies that worked for human developers require engineering effort that does not scale with agent-based workflows.
The Migration Strategy#
Scarf deployed a Python API server alongside their existing Haskell code, gradually routing new functionality to Python while legacy Haskell remained operational. No dramatic cutover, no rewrite-from-scratch panic.
Press reports measurable productivity gains through what they can now "ship with high effort, with minimal oversight, and even what we can ship fully automatically." Test coverage improved significantly. Hotfix deployment became "literally one slack message away."
On the type safety tradeoff: "The type safety we gave up hasn't been noticeable in any concrete way yet, especially considering our test coverage has never been better."
What HN Is Saying#
The Hacker News thread produced heated debate, with several distinct camps forming.
The type-system advocates are skeptical. One commenter wrote: "I can't imagine using a language without a good type system to catch all the junk the LLM produces." The intuition is that expressive types should be more valuable when AI generates code - you want the compiler catching mistakes the model makes.
Another pushed back on the premise itself: "I've found LLMs to be best with more constrained type systems: they are better at OCaml than they are at TypeScript." The theory here is that constraints narrow the search space, making it easier for the model to produce correct code.
Python's type tooling gets criticized. A commenter described setting up a Python project at work: "Just setting up the editor needed me to use 2-3 tools out of: pyright, basedpyright, ruff, ty, mypy, and possibly other tools I'm forgetting that kind of do the same thing but throw errors in different parts of the codebase."
The comparison to TypeScript came up repeatedly. One team chose TypeScript over Python specifically for more consistent tooling, noting that "LLMs don't seem noticeably worse at TypeScript than Python" for agentic coding.
The compilation-time critique lands with some. A Java developer noted that cold compiles can hit 15+ minutes on large projects if you kill all caches. But they questioned the overall logic: "I'd look at people a bit oddly if they said: 'We didn't want to set up CI caching and compiled languages took 30 minutes per run so we changed our entire codebase to Python.'"
The counterargument is that caching across dynamically spawned VMs is harder than it sounds, and most build systems are not optimized for it. Whether fixing that is more work than a full rewrite depends on your codebase and team.
Commenters debate whether formal verification is coming. One argued that proving code correct has been an active research area for 40 years with mostly null results - "the juice just isn't worth the squeeze." They expect this will not change with LLMs.
Others see AI changing the economics: "A high-level spec is far easier to read and reason about than the reams of code required to actually implement something." The claim is that AI can draft coherent, verifiable specifications and prove conformance, making formal methods practical for projects that previously could not afford them.
One commenter from a "very, very large company" reported they are "rapidly going all-in on formal verification across projects we never would have dreamed of verifying before."
The Haskell community gets direct criticism. Press warns in the original post that "Haskell is in real danger," arguing the community's resistance to AI-assisted workflows contradicts practical industry needs. He advocates prioritizing "build times, onboarding, documentation, examples" over advanced type system research.
A commenter suggested this may be a self-fulfilling prophecy: if the Haskell community does not adapt to agent-driven development, the language loses relevance regardless of its technical merits.
The Broader Trend#
This migration reflects a pattern appearing across the industry. Languages and tools are being evaluated against a new criterion: how well do they support AI-assisted workflows?
Fast feedback loops favor interpreted languages or fast-compiling ones. Go's compilation speed becomes an advantage. Python's ubiquity in AI tooling creates network effects. TypeScript hits a middle ground with reasonable type safety and fast iteration.
Haskell's strengths - expressive types, strong guarantees, advanced abstractions - do not disappear. But if the development loop includes "wait 90 seconds for compilation" repeatedly, those strengths compete against raw velocity.
Press explicitly frames this as economics: when an LLM produces implementations in minutes, any friction in the verify-and-iterate cycle becomes expensive. The language that wins is not the one with the best type system - it is the one that minimizes the time from "generated code" to "running tests."
The Practical Takeaway#
For teams evaluating language choices in 2026, this adds a new dimension to the decision matrix. Ask: how does this language work with agent-driven development?
Consider:
- Cold start compilation times in fresh environments
- Caching complexity for distributed CI
- Tooling maturity for LLM-generated code analysis
- Community investment in AI-assisted workflows
The tradeoffs are real. Type safety catches errors; compilation time slows iteration. Test coverage can substitute for some type guarantees. The right answer depends on your codebase, your team, and how heavily you lean on AI assistance.
Scarf made their choice. It cost them Haskell's guarantees and gained them velocity. Whether that tradeoff works for your project is a question worth asking explicitly rather than discovering the hard way.
FAQ#
Why did Scarf move away from Haskell?#
CEO Avi Press says LLM-driven development made Haskell's compile times a bottleneck: if an LLM can produce a working implementation in minutes but the compile step takes dramatically longer, the language slows the whole loop. It was not an emergency migration or a technical failure.
How did Scarf migrate from Haskell to Python?#
Scarf deployed a Python API server alongside the existing Haskell code and gradually routed new functionality to Python while the legacy Haskell stayed operational, with no dramatic cutover or rewrite from scratch.
Did Scarf lose anything by giving up Haskell's type safety?#
Press says the type safety they gave up has not been noticeable in any concrete way yet, especially since their test coverage has never been better. Type-system advocates on HN remain skeptical.
How should teams factor AI coding into language choice?#
Look at cold start compilation times in fresh environments, caching complexity for distributed CI, tooling maturity for analyzing LLM-generated code, and community investment in AI-assisted workflows.
Continue Reading#
- Workers RPC Now Bridges Python and JavaScript: No Schemas, No Serialization Code
- GitHub Copilot for JetBrains Gains Persistent Memory and Ollama BYOK
- Claude Context Is Code Search For Agents. Treat It Like Retrieval Infrastructure.
- Project Valhalla Arrives: Value Classes Ship in JDK 28 After a Decade of Work
- Ruff v0.16.0: 413 Default Rules, Markdown Formatting, and What Zero-Config Linting Means for Python
- Elm's Road to 1.0: Faster Builds and the Acadia Future
Sources#
- After 7 years in production, Scarf has reluctantly moved away from Haskell - Original article by Avi Press
- Hacker News Discussion - 193 comments, 161 points
Get the next deep dive like this in your inbox
One email a week on News and the rest of the AI dev stack. Free.
Read next on AI coding tools
Ruff v0.16.0: 413 Default Rules, Markdown Formatting, and What Zero-Config Linting Means for Python
Ruff v0.16.0 turns on 413 default rules, adds Markdown code-block formatting and ruff: ignore comments. What changed and why zero-config linting matters.
5 min readThe Human-in-the-Loop Is Tired: Pydantic on AI Dev Burnout
Laura Summers of Pydantic articulates why LLM-assisted programming increases work intensity while eliminating the rewards that made coding satisfying.
7 min readSix Weeks After the Bun Rust Rewrite: Is It Done Yet?
The Bun Rust rewrite six weeks on: 2,475 open bot PRs, no release tag and costs that may exceed $165K. The evidence, Jarred Sumner's reply and HN reactions.
8 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.
