I know sometimes it gets some hype but Haskell and its ilk is just so above the quality of any other language it's mind bending. Whenever a hard language design problem comes up in any new language, Haskell has solved it more than 2 decades ago.
The ecosystem (Hackage etc) is pretty bad though.
The language might be elegant at the core, but it's too far removed from reality (efficiency on real computers is super hard to control from Haskell) and it's far too focused on types (which, while they catch some errors, slow development down, and encourage unnecessary complexity ("easier" and "more type-safe")). After all, it's an academic language.
It's understandable to show skepticism about "the new shiny thing" (although Haskell is > 30 years old) because most new shiny things turn out to be not that great after all. I've been struggling to communicate the "no, but really" distinction without much success to other people and it's frustrating.
(...for purely egoistical reasons though, I don't really care what people are using as long as I get to use a sane language in my day job, which is currently not the case.)
If you think this is smugness, look into it. The features that come up with GHC extensions have no equivalent in other languages, because the commonly used stuff in Haskell so far ahead.
Current debuggers are built around very imperative notion of program state. I have breakpoints, I can look at variables (state in a given time)..
What would debugging look like if we looked at it from the functional perspective?
For example, execution "filters" instead of breakpoints. What happens if this function receives value that satisfies certain condition? Instead of variable watches, give out a breakdown of the data passed in and out from the function. Etc.
I think this has more to do with lack of polished UI editors (build tools) than with the language.
One could easily say that Qt was pleasurable because it was a well designed object-oriented and inheritance based toolkit. I have my reasons to believe this is objectively better within the context of UI design, and that pure functional programming in GUI design will never break out of it's magnificently tiny niche, but I'm not gonna go into that here. I'd rather just point out that some shared theoretical idea behind both Qt and Haskell UI design doesn't in any way imply that Qt's success could be Haskell's as well. Only Haskell programmers, working in Haskell code, could prove that idea. And if it really is that great, then surely they could do it.