I find this article much more interesting than op.
In particular, the focus on keeping functional codebases simple is, I believe, the core of what makes a successful functional codebase.
Basically, at some point when working languages like Haskell, Scala or F#, you are given a choice between power and ease-of-hire/onboarding. Apparently, they made the second choice, which I believe is the good one in their situation.
I believe it is possible to stick to functional languages and make a team-enforced decision to keep things simple, but the choice of simply opting out of it is also on the table, and I won't blame them for it.
I would just have preferred having a simple language AND a great type system.
In particular, the focus on keeping functional codebases simple is, I believe, the core of what makes a successful functional codebase.
Basically, at some point when working languages like Haskell, Scala or F#, you are given a choice between power and ease-of-hire/onboarding. Apparently, they made the second choice, which I believe is the good one in their situation.
I believe it is possible to stick to functional languages and make a team-enforced decision to keep things simple, but the choice of simply opting out of it is also on the table, and I won't blame them for it.
I would just have preferred having a simple language AND a great type system.