nkpart: Why haskell? Super cheap upgrades. Major compiler versions, major library versions, no worries.
parqit: @nkpart can you please elaborate on "cheap"?
For sure!
At veitchlister.com.au, we use a mix of Haskell and Ruby (with a smattering of Java and C++ around as well). As you can imagine, there are stark difference when you are maintaining code across these ecosystems! We have been doing this for a few years now, such that we have code in all languages that has been around for at least a few years, and we've been through large refactors, system upgrades and dependency upgrades in each.
When we're upgrading dependences of the ruby components, we expect things to fail. We have testing, but we also have 100k lines of Ruby and 3 developers. I do not expect (nor do I think it's efficient) that testing will catch all of these problems. "Ship and support", is the unspoken mantra. Deploy the code and then be on call to help out our users.
On the flip side, we have learnt that the haskell code will not fail when we upgrade components. I am not being hyperbolic, that is simply our experience. We bump version numbers in dependencies, we allow the development tools to tell us what we need to do upgrade our codebase, and then we ship.
Perhaps another way to demonstrate how the business sees the cost: upgrading a major ruby version would be a project in our timesheet system (engineering consultancies seem to love these things), upgrading a major GHC version is a job to do before morning tea.