In this episode, we are joined by Rebecca Skinner. She talks about her new book, Effective Haskell, which takes you from list manipulation to thunks to type-level programming. She also tells us about large scale industrial applications in Haskell, and how the architecture is shaped by the organization of the engineering teams.
Until the end of this year, you can use the code INTERLUDE to get a discount on her book!
snippets from the epsiode transcript
RS (0:30:50): Yeah. So, Mercury is a fintech company. … We’re built entirely on Haskell in the backend of our application. So, I think we have—oh, I don’t even know how many lines of code we have—something like five or 6,000 modules in our code base and over a hundred engineers. I think about two-thirds of the engineers are working on Haskell.
MPG (0:31:34): So how does it work with Haskell at scale? How do you organize that?
RS (0:31:41): Yeah. So I think that right now we are really at a point where we’re feeling the scale that we have. And I think we’ve historically had our application just be a single – I don’t want to quite say monorepo because we have a separate repo for our front end, but a single large backend application.
…
But it’s all essentially one Haskell library. A big one. And we put a lot of effort into making the tooling and the ecosystem work well with such large products.
X posts (Twitter tweets)
We recently broke 1M lines of Haskell code in the repo
https://twitter.com/mattoflambda/status/1724898293728325967
Haskell compilation time is impressive. We have a single package with 6800 modules and over 800kloc and a complete build is about five minutes.
Ghci feedback is super quick with cabal repl —repl-no-load to only load the subset of modules you’re working on
Haskell tooling
https://twitter.com/mattoflambda/status/1712820271068094865
about modules, packages, projects and upgrades at scale
Mercury has one library with 6,000 modules (or 6,800 over 800kloc). It would be good to know more about this codebase:
Do you use a project; a stack project, a cabal project or both types?
How many dependencies? How many source repository packages? How many forks?
Are test suites and benchmarks in the same package?
How is the production build done?
Is there another grouping of modules?
a. Is gradual and isolated upgrading (of compiler and dependencies) possible?
b. Are there other projects for upgrades?
c. Is upgrading driven by some kind of TODO list?
d. If not gradual, then is upgrading done by way of branching and only merged when complete for all modules?
I’m the author of Updo, tooling for project maintenance. Its upgrading TODO list feature works when modules are spread over many packages, not one. It can work with projects having a single package too but upgrades in that case would not be gradual over modules and dependency versions unless falling back on cabal conditionals, mixins and CPP conditionals.
