> The problem is that creating industry friendly libraries is apparently not a goal that the Haskell community has.

I don't think that's a fair take. Haskell started as a research language, and it's only in the 2010s really that it started taking off and becoming more and more practical. That's because people invested lots of effort in libraries like lens (and many others). Haskell didn't even have a strong build system until Stack popped up in the mid-2010s. Frankly these were bigger priorities. These things had to be solved first in order to transition Haskell from a research experiment in lazy evaluation into a real-world tool.

In 2020, outside of maybe dependent types, the community is probably more concerned with practicality and pragmatism than ever before. There's a huge focus right now on improved IDE support, for instance.

10 years should be enough time to get a working IDE and a good starting set of libraries, and my personal experience is that Haskell has neither.

Maybe you ran into an issue where there still isn’t a decent starter library, but there are actually tons of great ones out there that we’ve used to build production services. So I can’t say I really know what you’re talking about in general.

Language server support is a recent trend, and it’s being worked on for Haskell just like it is for everything else.

People put energy into what's most useful for them and I don't think they should be blamed for this. I'm sure I'm biased but Lens and Parseq (and its successors) are both amazing libraries solving real problems in a powerful way. You probably don't agree and that's perfectly fine by me. I'd also go as far as saying that the 2 libs you've picked actually have pretty comprehensive documentations as well which is not always the case with Haskell libs (a real problem I 100% agree with btw).

I’m not blaming them, mostly, but I am pointing out that what they’ve put their effort is not consistent with industry usage. Parsec is neat, but parsing is a relatively niche industrial need, and lens sits somewhere between PL research and “solving problems that only Haskell has”.

They’re fine libraries, they’re just not what I want to see if you’re trying to convince me to replace Java with Haskell at work. If I was looking to write a compiler however...

I think when framing it as a chicken and the egg problem, haskell communities take on it is that you don't need a nest for the chicken to hatch in.

Brutalist Software engineering.

Usage based data implies that you actually do need a nest for an chicken to hatch in.

If you want chickens to hatch reliably, you need a coop too.