I heard Haskell is a poor choice for real-time systems and numeric computation. It's kinda ironic that a language as "mathy" as Haskell is such a poor choice for doing actual math. Assuming these things are true.
This definition of "the real math" is quite arguable. Doing a lot of computations efficiently is a realm of modeling and statistics; that does not clarify the very nature of computation, the inner laws of formal systems. Haskell is much more about "what computation is" than about "how to do computations".
Besides that, from mathematician's point of view, "efficient numerical computation" is a necessary and useful practically, but very ugly thing. Speaking of C-like types `int`/`long`/`uint32_t`: they are only a crude approximation of natural numbers, they are a ring modulo 2n, which we pretend to use as natural/integer numbers, silently failing when this range wraps up.
And that is not the end of the story: for integer numbers we can at least specify what mathematical model describes them (a ring modulo some power of two), for floating point numbers it is impossible: set of possible IEEE 754 values is a very weird and irregular finite set of values (NaN, +Inf, -Inf, +0, -0, exponential distribution of points density with min/max bounds) with complex modes of failure. Associative law, distributive law, commutative law? The very equality check? Forget about it, floating point numbers have none of that.
If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that).
While quite fast, it is not in the league of low level programming languages. If you need ridiculous speeds, you don't have another choice but to use C, C++ or Fortran.
Python has a lot of very useful modules. If I can solve my problem with basically a few import statements and don't care about performance or anything, I find Python to be better suited.
Erlang's light-weight threads are a boon. Having a webserver written in Erlang and using Erlang as a server-side language, you can support a lot of sessions at once.
Haskell does support mutable arrays. Your code that does the mutating will have to live in IO (or perhaps ST), but the downsides of that are exaggerated.
Haskell strikes many as "bad for mutation" because introductory tutorials don't really cover it. This is because 1) mutation is not terribly idiomatic, 2) relying on mutation often (not always) a bad design decision, 3) Haskell handles the immutable case really well, and 4) mutation involves some more complexity than is involved in other languages. All of these are good reasons to avoid talking about mutation in a beginner Haskell tutorial, but when you need to address a problem where mutation is the best fit you'll find that it actually works pretty well. Haskell doesn't make mutation difficult, it makes it explicit, which has upsides and downsides.
> If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that).
Haskell does support mutation, it just requires it to be controlled. Take a look at Data.Array.ST and Data.Array.IO
> Erlang's light-weight threads are a boon. Having a webserver written in Erlang and using Erlang as a server-side language, you can support a lot of sessions at once.
GHC provides a very similar thing in the form of "green threads".
> If you have an array that fills a significant fraction of your memory (say, tens of Gigabytes), you don't have another choice but to use mutation (Haskell doesn't support that).
Haskell supports mutation, although many short tutorials don't address it and even many longer tutorials don't do much with it.