Haskell is our first choice for building production software systems

> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development.

the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string> and what the fuck is that shit I just want to make games !!11!1!

In contrast Haskell is often self-taught which gives a very different set of incentives and motivations.

As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system is one of the most important part of my job and make the language very easy to use when you use an IDE which allows to click on an error and going to the right place in the code.

I learned both Haskell and Rust self-taught an still find the latter's type system a bit of a cage for it's lack of higher kinded types, frankness be.

I know not much of Java, but my sentiments concerning C++ are even worse.

I do not regularly program in Haskell and far more often in Rust.

Someone has to take the first step to solve the chicken and egg problem. If there are jobs requiring Haskell, it might get more users.

Haskell is nice and all, but I'm not a huge fan of this take. I can't help but think that many of the arguments boil down to something like 'you can write types so that the compiler checks things for you' (not a quote), whilst the author disregarded the Java/C++ compiler as "an annoyance" (a quote). The rest of the article is mostly a comparison between Haskell and PHP/Python/JavaScript, and most laid out benefits boil down to static typing.

Sure, Haskell's type system is nicer, and the error messages are, I'm sure, more helpful (although the Java/C++ ones make sense when you learn what they mean).

There is an example of domain modelling in Haskell:

    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

The syntax is nice (ish, CustomerInvoice is a bit ugly), and terse. But, I've seen this a million times in Java, and that works fine.

Quote:

  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.

All of this is table stakes in Java/C++ too.

Other brief rebuttals:

  Haskell has a large number of mature, high-quality libraries

No way this beats Java. I don't know the C++ ecosystem well, but I assume C++ wins too.

  Haskell enables domain-specific languages, which foster expressiveness and reduce boilerplate

Be careful what you wish for.

  Haskell has a large community filled with smart and friendly people

I think at the end of the day Haskell just feels fun to write, if you're the sort of person that likes it. That's fine. But I don't think going all-in on Haskell is the right call for most companies.