Real-world Haskell: Good, Bad, & Ugly
summary
A Vacation Labs team describes their year-long experience adopting Haskell after extensive Rails and JavaScript work, aiming for safer refactoring, more effective testing, shared data structures, and maintained feature speed. They discuss the Haskell ecosystem’s practical strengths and weaknesses for real-world production code (34k lines), and note they use TypeScript rather than Haskell on the frontend.
AI-written summary · about
chapters (23)
- 0:00Intro
- 0:21Haskell Joys & frustrations of putting 34,000 lines of Haskell into production
- 4:20Vacation Labs Travel-Commerce Platform
- 6:35Problems with Rails/JS Code
- 10:12Haskell. First, the GOOD parts.
- 13:28"Type-safe" : "JSON"
- 15:47Big problems faced first-hand
- 16:17Library ecosystem is effectively broken
- 19:32Emails
- 21:55Sendgrid library
- 25:18DB libraries
- 26:06Lack of established best-practices
- 28:28Installing Haskell
- 30:27Error handling
- 32:43Error reporting
- 38:42Absence of CallStacks can probably be fixed
- 40:20Testing
- 44:07Important caveat about memory usage
- 44:46Recommendation: Editor tooling
- 45:31Shout-out to HIE (Haskell IDE Engine)
- 50:25DB Library. Dare I say ORM?
- 51:49Associations?
- 52:43Validations?
related talks
32mHeadfirst into Haskell
55mModern Software Development with Haskell
31mWhy Haskell is a Terrible Choice for Startups (And Why We Picked It Anyway)
53mIntro to Haskell for Erlangers
40mWhat Haskell taught us when we were not looking
01h 04mHaskell - A Peek Inside the Ivory Tower
52mBuilding Scalable Web Applications with Haskell
38mWhat Haskell Taught Us When We Weren't Looking
