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.