After 7 years in production, Scarf has reluctantly moved away from Haskell
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.