I did the same and I treat Haskell as a rite of passage. At this point it's cliche to say that Haskell makes you a better programmer in other languages, but it's true. You really immerse yourself in Haskell for a few years, and you become a better programmer even when you aren't writing Haskell. I'm referring to universal things like "making invalid states unrepresentable" or "preferring to parse than to validate" or "functional core imperative shell" that can work well and lead to cleaner code in any language.
(The actual reason I left Haskell was because I switched my employer. Choosing an employer is IMO a bit more important than choosing the language to code in.)
I've bounced off haskell several times now (I'm probably due another attempt this year, I continue to be convinced the problem is one or more 'aha' moments that I just haven't managed to make click yet).
The "functional core, imperative shell" approach is -fantastic- though and I'm not sure where I picked it up from but a lot of my (especially async/event driven) code looks at least close to that.
It occurs to me that this may be why I've yet to be significantly bothered by function colouring when writing async/await based code in Perl and/or JS, but I'd probably have to give that more thought before I go beyond 'maybe' with that particular idea.
I agree with you. The function coloring "problem" in the Haskell world is basically the distinction between a pure function and an IO function. I put the word "problem" in quotes because it's abundantly clear to any Haskeller that it isn't a problem but rather a beneficial constraint on programming that, sadly, other languages don't enforce in their type systems. The whole point of type systems is to add constraints and prevent you from writing certain hopefully nonsensical programs (if not we might as well go back to untyped lambda calculus which is Turing complete). Haskell just goes further than most languages. When you stick with this kind of constraints, you eventually naturally lead to approaches like "functional core imperative shell" which is an improvement in code quality and clarity.
For a junior programmer, the benefit of such constraints is greater because they do need the compiler to tell them no. The benefit is somewhat reduced for senior programmers because experience leads them to naturally avoid things that a Haskell compiler would have yelled at them for.
(The actual reason I left Haskell was because I switched my employer. Choosing an employer is IMO a bit more important than choosing the language to code in.)