I worked on around 25 industrial Haskell codebases during consulting at FP Complete. I also participated in groups of Haskellers learning Rust. This topic is very interesting to me. Some things that come to mind:
- Every line of code, in any language, is a liability. Haskellers don’t treat code as a liability; especially juniors but also seniors, they rewrite everything in it, try out weird abstractions, use packages with a single maintainer for a core product feature, etc.
- The novelty budget is a very apt guide. When you use up your novelty budget, it’s very high chance that your project will be dropped and rewritten in $popular_lang. Haskell takes a big chunk of the novelty budget already, but Haskellers use more of it than necessary.
- The tooling problem is real. It is terrible and has been since I started in 2009. That makes Rust look attractive. Also, people don’t want to have to learn Nix to build their code projects. But ecosystem churn makes CTOs look back at Java.
- The compilation speed problem is real. If you count your CI build time in tens of minutes to an hour, rather than seconds, chances are you’re using Haskell and not Go. That makes Go look attractive.
In my view, the best way to use Haskell in industry and avoid it being dumped or rewritten is to be parsimonious, use existing packages from other languages that already work, minimize the upkeep required (think Casio watch vs Tamagotchi). Otherwise that codebase will get the chop.