 Haskell is our first choice for building production software systems
Haskell is nice and all, but I&#x27;m not a huge fan of this take. I can&#x27;t help but think that many of the arguments boil down to something like &#x27;you can write types so that the compiler checks things for you&#x27; (not a quote), whilst the author disregarded the Java&#x2F;C++ compiler as &quot;an annoyance&quot; (a quote). The rest of the article is mostly a comparison between Haskell and PHP&#x2F;Python&#x2F;JavaScript, and most laid out benefits boil down to static typing.<p>Sure, Haskell&#x27;s type system is nicer, and the error messages are, I&#x27;m sure, more helpful (although the Java&#x2F;C++ ones make sense when you learn what they mean).<p>There is an example of domain modelling in Haskell:<p><pre><code>    type Dollars = Int

    data CustomerInvoice = CustomerInvoice
        { invoiceNumber :: Int
        , amountDue     :: Dollars
        , tax           :: Dollars
        , billableItems :: [String]
        , status        :: InvoiceStatus
        , createdAt     :: UTCTime
        , dueDate       :: Day
        }

    data InvoiceStatus
        = Issued
        | Paid
        | Canceled
</code></pre>
The syntax is nice (ish, CustomerInvoice is a bit ugly), and terse. But, I&#x27;ve seen this a million times in Java, and that works fine.<p>Quote:<p><pre><code>  Modeling domain rules in the type system like this (e.g. the status of an invoice is either Issued, Paid, or Canceled) results in these rules getting enforced at compile time, as described in the earlier section on static typing. This is a much stronger set of guarantees than encoding similar rules in class methods, as one might do in an object oriented language that does not have sum types. With the type above, it becomes impossible to define CustomerInvoice that doesn’t have an amount due, for example. It’s also impossible to define a InvoiceStatus that is anything other than one of the three aforementioned values.
</code></pre>
All of this is table stakes in Java&#x2F;C++ too.<p>Other brief rebuttals:<p><pre><code>  Haskell has a large number of mature, high-quality libraries
</code></pre>
No way this beats Java. I don&#x27;t know the C++ ecosystem well, but I assume C++ wins too.<p><pre><code>  Haskell enables domain-specific languages, which foster expressiveness and reduce boilerplate
</code></pre>
Be careful what you wish for.<p><pre><code>  Haskell has a large community filled with smart and friendly people
</code></pre>
I think at the end of the day Haskell just feels fun to write, if you&#x27;re the sort of person that likes it. That&#x27;s fine. But I don&#x27;t think going all-in on Haskell is the right call for most companies.