Why Haskell is a Terrible Choice for Startups (And Why We Picked It Anyway)
summary
Production Haskell backend serves about 200 million downloads a month and grew to 350,000 lines of Haskell, but costs show up as long GHC compile and dependency fetch times, brittle upgrades (Aeson/GHC bumps), and frequent missing bindings that forced building things like RocksDB bindings and hand‑patching a slow Stripe library. CI and caching workarounds plus a half-hearted Nix migration reduced pain but added complexity, while refactoring speed and strong types repeatedly save time and make the tradeoff tolerable.
AI-written summary · about
chapters (15)
- 0:00Introduction and title
- 0:10Why Haskell for startups?
- 3:42Hiring challenges with Haskell
- 6:04Missing libraries and ecosystem
- 9:15Build times and tooling pain
- 12:28Dependency upgrades and brittleness
- 14:10Correctness vs startup speed
- 16:56Embracing imperfect products
- 17:59Haskell brain and elegance
- 20:26No single way to write Haskell
- 22:12Unexpected complexity in practice
- 24:22Why we chose Haskell anyway
- 27:33Haskell is fun to use
- 28:15Community asks for improvement
- 30:42Final thoughts and conclusion
related talks
57mReal-world Haskell: Good, Bad, & Ugly
32mHeadfirst into Haskell
52mBuilding Scalable Web Applications with Haskell
55mModern Software Development with Haskell
53mIntro to Haskell for Erlangers
29mBrave New World, tales of PureScript and Haskell in production
38mWhat Haskell Taught Us When We Weren't Looking
54mQ & A Session With Functional Conf Speakers