That's why I like Python over Go, C# and others. Python lets me fit more functionality (expressed as code) in my working memory, and I have to ignore less line noise and boilerplate.
ps: note that I'm not criticizing FP or static/math oriented programming. I'm just trying to pu both sides into a shared perspective
And that's what it comes down to, almost always. How hard is it to hire other people to work on your code, and how hard is it to bring people up to speed, who need to code, but aren't programmers. Scientists, mostly. Business people increasingly.
Jane Street, for example, went with OCaml in part because the business people found the code easier to review than other languages.
That said, the fact that OCaml is used by Bloomberg and Facebook (on multiple apps and products) alone make it not niche http://www.ocaml.org/learn/companies.html
That plus ReasonML's growing popularity, which is essentially just a syntax extension of OCaml, makes it even further not niche.
And that counts in all sorts of ways. You'll have much more trouble finding answers to any questions you have. You'll have less chances for community meetings or educational content. You'll definitely have more trouble finding new developers for your projects, both in business and in open source.
Erlang doesn't support mutation at all, for example, and uses immutable types for everything. But it does let you send messages to other processes, which is a side-effect, so Erlang is not purely functional. But that doesn't mean that JavaScript is somehow just as functional as Erlang. Because it's not.
Starting with Haskell is a bad idea, no doubt.
But there are easy to use functional languages that are very beginner friendly, like Elixir or Elm.
I not sure I agree. The university I went to used Haskell for its introduction to programming courses and I think it worked pretty well for most people, and especially for people who had never programmed before. The people that did struggled the most where actually those who already knew a bit of programming, but weren't very strong programmers.
The flip side is that all the students who had now had been introduced to programming via Haskell where completely confused when trying to understand OO and Java in the next course.
It's easier than teaching them imperative programming, because it's much easier to reason about.
The real problem is teaching functional programming to programmers whose brains have been damaged by years of writing imperative programs.
Especially C++ and C# are notorious for hiding what actually happens, and in a worse way. Their performance however is more predictable, which is important in some cases.
There's not a lot of difference between usage of such modules in Python "hiding" complexity and abstractions used in Java, C#, C++ or Rust except those languages don't actually need to use FFI to get acceptable speed. Computer Science is pretty much just layers and layers of abstractions and the level of abstraction that Go or Python chose to operate on isn't special in any way.
I only meant to say that in my opinion something like C++ "hiding" behavior in libraries, classes or through operator overloading is not different from Python where easy to use modules hide extreme amounts of complexity. In fact, C++ is better, because it uses FFI way less than Python and by being a lower level language it limits the maximum possible difference in abstraction level between visible and "hidden" code.
Preemptive strike against whitespace comment.