After 7 years in production, Scarf has reluctantly moved away from Haskell
As one company rewrites its long‑running Haskell backend in Python to better suit AI code-generation “agents,” developers clash over whether this trade sacrifices too much type safety and performance for faster feedback loops. Many argue that strong, static type systems are more valuable than ever for constraining LLM output, and suggest alternatives like OCaml, Rust, Go, or Java that combine types with quicker compiles, while others counter that Python’s ecosystem, training data abundance, and zero compile time make it a pragmatic choice for rapid, AI-assisted product work.
Role of Types with LLMs
- Many argue strong static types are more valuable with LLMs, catching “junk” output and making AI‑generated code easier to understand and refactor.
- Others highlight that LLMs often avoid or quickly fix simple mistakes themselves, so the marginal benefit of very strong type systems may be lower than before.
- There’s disagreement on whether LLMs reduce the need for type safety or make it more critical; several commenters explicitly find the “less type safety” conclusion baffling.
Compile Times and Agent Workflows
- Central complaint: Haskell’s slow cold compile times become a severe bottleneck for agentic workflows that frequently build and run tests, especially across multiple worktrees/agents.
- Some counter that fewer, richer compiler checks can offset slow compiles, but acknowledge that a 15‑minute base cost is hard to amortize.
- Several note this problem already hurt human productivity; LLMs just make it more visible. Others suggest better build caching/infra as an alternative to rewriting.
Python vs Other Language Choices
- Many are surprised the move is to Python rather than TypeScript, Go, OCaml, Rust, Java, C#, F#, etc., which offer stronger typing with decent compile times.
- Defenses of Python: team familiarity, huge ecosystem, abundant training data for models, and no compile step.
- Critiques: weak and fragmented typing ecosystem, need multiple type tools, inconsistent annotations in libraries, numerous “footguns” for servers, and poorer runtime performance.
Experiences with Haskell and Alternatives
- Some report very productive Haskell+LLM workflows and don’t see compile time as a major issue in practice.
- Others have already left Haskell (e.g., for Rust) due to laziness, exceptions, ecosystem size/fragmentation, and tooling pain.
- OCaml, Lean, F#, Go, and JVM languages are repeatedly cited as promising middle grounds: fast compiles plus useful types.
Broader AI‑Era Reflections
- Debate over whether we’re moving to a “post‑language” world where agents drive language choice by efficiency (runtime, token cost, wall‑clock).
- Concern that optimizing for “vibecoding” speed may erode engineering rigor and long‑term maintainability.
- Some argue future languages must choose: design primarily for humans or for agents; these goals may conflict.