Haskell is our first choice for building production software systems

If a significant part of those types was just something like `std::collections::` or similar then I'm not sure I see the problem.

Suggestions should probably trim redundant prefixes like that, but recognizing standard library namespaces shouldn't be a big obstacle to understanding either.

SML and OCaml also have global inference, and in fact Haskell initially got it from there.

A lot of the "weirder" parts of Haskell are there because early on Haskell was pretty much "LazyML" and then it started growing into something different.

> fmap renderPost postList

for(var post: postList) renderPost(post);

Or

postList.stream().map(renderPost)

I think saying "packages" was an error on my part, because how this is different from the usual C++/other language example is that Haskell is a ML language, and gives you a lot of abstractions (rather than packages per say) to use. Generally using packages in haskell is easy because you don't care what abstraction they were written in (almost always IO is there somewhere, or they offer a doTheThingIO function which is the lowest common denominator), and if they're completely functional libraries then it really really doesn't matter.

The commenter was railing against the abstractions the codebases used, not the underlying packages actually. I don't want to get into explaining it, but it is very easy to write production-ready simple haskell, but also very easy to spend hours building abstractions in the type system (normally) to build yourself a straight jacket. OK so if I explain it a little bit, there are at least three ways that have surfaced in recent time (lets say the last 5 years) on ways to structure large effectful haskell codebases (which is most software you'd want to write).

- Everything in IO (just do everything in the IO monad)

- monad stacks & transformers

- The ReaderT pattern

- Effects (free/freer, polysemy, fused-effects, etc)

All of these approaches have high quality libraries to support their use, but you could stay at that first one (everything in simple IO) and be very happy for a very long time.

I'd argue that C++'s problematic features are of a different nature -- when one of them goes wrong you normally have a much more disastrous outcome (whether at runtime or when you're trying to grok the code). For example compare C++'s templating system to haskell's support of generics for example, one is infinitely safer to approach and easier to understand than the other for the simple case, due to how the languages are built (i.e. no inheritance). Haskell it's more up to you to strangle yourself with the complexity -- the necessary abstractions are pretty simple (typeclasses, monads are simple in use, if not in concept), but the unnecessary abstractions basically scale to PhD.

I will absolutely concede that Haskell does encourage you to reach for higher and higher levels of abstraction for diminishing returns. But I will take Haskell's abstractions over Java's abstractions any day of the week, even though Haskell's can be more inscrutable.

That's just untrue and Paul Graham wrote a great essay on that(Python paradox, mentioned in another comment in this tree). I have been working with Elixir for last 5 years, so I guess I can give some first hand opinion.

1. When your company uses esoteric language, your job offers usually have "we can teach you the language" instead of "we require x years experience in language and y, z libraries)". That is a really great filter for people you want to work with, as they have to accept they will be learning from the start.

2. There is a smaller number of engineers qualified, but the number of companies they can apply to is even more reduced. I think all in all you're winning in this equation as a hiring manager.

3. Your hiring process get cheaper, since it moves from having to filter candidates heavily to focus on matching the right person for the team. People who are interested in non-mainstream languages already fit some of the criteria you have to select for otherwise.

4. As the number of people to hire easily is smaller and onboarding even a talented person without experience in tech takes time, you get much better with selecting problems you want to tackle and grow in more reasonable pace. That has great benefits for your organisation.

I know for sure that if I am ever starting my own startup, I will use no mainstream technology. If I want JVM, I will use Clojure instead of Java, if I want web, I will use Elixir instead of Rails/Django, if I go low level, it's Rust, no C++ etc.

It's counterintuitive, but it works better. People think about size of the whole market, but they should think about percentage of candidates applying being fit for the job.