필사 모드: Why Scarf Reluctantly Left Haskell After 7 Years — The Real Cost of a Language Choice
English- Introduction — Leaving a Language You Love
- What Did Not Break — The Promises Haskell Kept
- The Real Reason — Compile Times and the Economics of Agents
- How They Left, and the Lesson That Remains
- Closing
- References
Introduction — Leaving a Language You Love
A "we switched languages" post is usually where a team airs its grievances. The piece Avi Press, the founder of Scarf, published in July 2026 is the opposite in tone. The title itself says the team left Haskell reluctantly. He has been a Haskell fan for sixteen years, and Scarf ran Haskell in production for seven. By his own admission he rarely writes things like this — he would rather build and promote than critique.
The question underneath the post is a good one: what actually makes a team abandon a language it still likes? Not a language that betrayed it, not one it was forced onto — one it chose freely and would defend in public. Answers to that question tend to be more honest than the usual flame-war fodder, precisely because the author has no axe to grind.
That is exactly what makes it worth reading. Scarf did not leave because Haskell fell over. If anything, Haskell kept most of its promises. And the reason people usually reach for first — that it is hard to hire Haskell developers — appears nowhere in his account. Avi's actual reasons are more specific, more 2026, and more worth chewing on.
What Did Not Break — The Promises Haskell Kept
Start with the credit side of the ledger. Avi is explicit that Scarf put Haskell through a serious production test and that many of its promises held. The code was reliable. The type system caught real bugs. The language forced the team to model its domain carefully. They ran services under contractually committed SLAs for years without drama, and high-performance code was generally straightforward to write.
The stack is concrete, too. The API was built on Servant and Beam over PostgreSQL, and the high-traffic Scarf Gateway was a performance-focused service written directly on top of WAI. These handled a large volume of open-source package traffic in production.
The most honest line is this: the type safety they gave up has not been noticeable in any concrete way so far. Coming from a devoted type-system fan, that admission carries weight. It cuts both ways, of course — the accidents that types quietly prevent are invisible by nature — but at least he refuses to inflate the loss.
There is a personal register here, too. Avi says learning Haskell made him a markedly better programmer, and you can feel that debt in the writing. That is the source of the reluctance: this is not a grudge being settled but a long relationship being renegotiated. It is worth keeping in mind before quoting the post as ammunition against the language.
The Real Reason — Compile Times and the Economics of Agents
So what went wrong? The two biggest factors Avi names are compilation time and ecosystem friction, and compile time is where the story turns distinctly 2026.
On a warm loop the cycle can be around twenty seconds, and that feels great. The problem is the cold start. Picture a development style where several AI coding agents each take a different branch in parallel — five agents exploring five branches at once. Each branch wants a clean, disposable build environment. If an agent drafts a plausible change in minutes and then waits fifteen minutes for a cold build, the compiler has gone from a papercut to the dominant cost of that thread of work.
Can't caching fix that? Avi's answer is unsentimental: caching is never perfect, and the engineering effort needed to make it good enough is itself part of the problem. The team spent real time tuning builds, caches, Nix, developer environments, and CI.
The core insight is an economic reframing. Agents are cheap at generating code and expensive when blocked. Haskell is optimized for catching errors at compile time — a genuine virtue when a human is the bottleneck. When an LLM can regenerate working code in seconds, the relative value of that virtue shrinks. The language did not get worse; what is expensive changed.
Put another way: for decades the received wisdom was to move error-catching as early as possible — shift left, fail at compile time, not at 3 a.m. That logic assumes the human writing the code is the scarce resource. Swap the scarce resource for a tireless generator that produces a candidate in seconds, and the bottleneck relocates to the latency of the feedback loop. A fast, dumber loop can now beat a slow, smarter one. That is an uncomfortable idea, and Avi does not pretend otherwise.
Avi also gestures, briefly, at community direction: a sense that type-system research is prioritized over build times, onboarding, documentation, examples, and tooling, and that around AI the conversation often seems more focused on restriction than enablement.
It is worth being precise about what ecosystem friction means here. Avi is not complaining that the libraries are immature or that things do not work — the stack above shipped for years. The friction is in the machinery around the code: the builds, caches, environments, and CI that a fast agentic workflow leans on constantly, plus a community whose energy points elsewhere. That is a different, and more interesting, complaint than the usual one.
How They Left, and the Lesson That Remains
The migration itself is textbook. All new API work starts in Python; a Python server runs alongside the existing Haskell one; requests are routed to the right place; and functionality moves over piece by piece as they touch it. That is the strangler fig pattern, and porting existing code proved fairly painless with an LLM doing the mechanical work. Haskell still runs in production, and the team still respects it.
There is a quiet irony worth naming. The same capability that raised the cost of staying — LLMs generating code fast enough to make the compiler the bottleneck — is what made leaving cheap. Porting to a new language, historically a brutal undertaking, is now largely mechanical when a model does the line-by-line work. The tool that changed the economics of building also changed the economics of migrating.
The results are stated honestly. Test coverage has never been better, and a hotfix is now one Slack message away. But Avi does not oversell the win — PR throughput did not obviously go up, commit volume is noisy, and lines of code, he notes, is a bad proxy for anything.
The lesson is not "Haskell is bad." It is that a language's fit is not an absolute; it is relative to how you build. The choice that was right seven years ago did not become wrong — the board changed underneath it. And the whole decision rests on one premise: that agent-driven development is how this team will build software going forward. If that premise holds, the move is, in Avi's telling, the clear and logical way forward. If it shifts, so does the math.
And it is worth naming the risk. Trading a proven strength for a bet is still a bet. If agent-driven development plateaus, or if the invisible bugs that types used to catch start surfacing at scale, the ledger could look different in a year. Avi's honesty about unmeasurable gains cuts both ways — the costs may be just as hard to see until they arrive.
So this is an n-of-1 story, one company's economics. It is less a prescription to rewrite everything in Python and more an invitation to re-measure, honestly, where your own bottleneck has moved.
Closing
The most instructive thing here is not the conclusion but the posture. Avi credits what Haskell did well, refuses to inflate what he gained, and is open that his decision stands on a specific premise. It is hard to leave a language this even-handedly. Whatever your stack, that honesty — the discipline to separate what held up, what changed, and what is still uncertain — is the part worth copying.
If there is a broader signal here, it may be this: as AI changes how code gets written, the axis we rank languages on is quietly rotating — away from how much a language prevents and toward how quickly it lets you try again. Whether that is progress or a trap is not yet clear. But teams that notice the rotation early, and stay honest about their own numbers, will make better calls than teams still optimizing for the old bottleneck.
References
현재 단락 (1/26)
A "we switched languages" post is usually where a team airs its grievances. The piece Avi Press, the...