Why Co–Star Uses Haskell
The fact that there are only two backend developers seems like a big asterisk to me.  It&#x27;s admirable how productive their backend team has been, but tiny teams are often surprisingly productive.  Communication costs and distributed decision-making often slow development a lot.<p>What I&#x27;m wondering, as someone who doesn&#x27;t know Haskell, is how well will it work if the team needs to scale?  Will they be able to find quality engineers?  Will those new engineers be able to easily pick up the pieces if one of the two engineers leaves unexpectedly?<p>I certainly am biased here, but pure functional programming has always seemed unnecessarily abstract and constricted for the purposes of most applications.  The communication of function and purpose to other engineers is an important responsibility of code.  Using long sequences of poorly-labeled, nested arrow function returns is great fun until you have the task of deciphering someone else&#x27;s.<p>To be clear, I am not suggesting all Haskell code is poorly-written or hard to understand.  But writing clear code is not a priority for a lot of engineers, and in my experience, functional programming can lead to especially opaque codebases.