> I feel that I can focus on actually building stuff with this language.
This is very much how I felt when using Rust as a previous production Haskell user. I enjoyed aspects of Haskell, and I'm still very impressed with it, but it seems to call up a kind of perfectionism that I don't experience nearly as much with other languages.
IME, the trick with perfectionism is knowing when to apply it. I.e, don't do it at the beginning but at the moment when the initial version starts falling through. Also, do it on the general area the issue lays (not "everywhere").
Absolutely. But with Haskell in particular, there are endless expressiveness micro-optimizations like "how can I write this point-free", "is there a combinator that would allow expressing this differently", "how can I express more of this in the type system"...
I am sure it's possible to write Haskell and just not fall into that trap, but I found that Haskell was especially prone to nerd-sniping the micro-optimizing part of my brain, in a way that other languages don't.
This for me sums up the library ecosystem and the type of folks who like using Haskell as a hobby. When I write production code, I aim to be as clear showing a good working design that's easy to understand (reading the issue/PR descriptions if necessary). The code style is chosen to maximize human comprehension. What I'm not doing is playing a game of one-upmanship with (virtual) others.
The only parts I'm really interested in optimizing are the bits that matter: factoring, naming, datastructures, algorithms, queries (for database), and minimizing abstractions that don't pay their weight.
I spent some time using F# out of curiosity of both it and OCaml and found that it was very easy to use with the exception of (mutable) arrays.
This is very much how I felt when using Rust as a previous production Haskell user. I enjoyed aspects of Haskell, and I'm still very impressed with it, but it seems to call up a kind of perfectionism that I don't experience nearly as much with other languages.