I'd suggest a better approach would be to advocate for doing a smaller project in Haskell with the part of the team that's on board, and steadily sell other people on how helpful the tooling (primarily the typechecker) is.

If you're working alone, you can write good code in any language, but when you're on a team, that means both getting everyone on the same page about what "good code" is, as well as actually maintaining that standard.

You might have someone who's quite good at getting things done, but thinks, for example, that dependency injection is not a virtue. It would be great to get all of your Ruby code referentially transparent to ease maintenance, but that means convincing this person to make the effort themselves - dragging them kicking and screaming is not in your best interest. More importantly, you have to make this argument without the promise of any tooling that benefits from being able to assume code is referentially transparent - this work does not get you a typechecker in the end, so your argument becomes "trust me", and your endgame becomes "manually maintain this standard forever".

The lesson learned from the formatting wars is that if you can externalize that responsibility into a tool, and show some tangible benefit from it, even if people have their own opinions, it stops being a major point of contention amongst developers - instead of "fix your code", you use a linter on new projects, and it becomes "spaces are just what the linter uses, it takes care of it for you, and we don't need to worry about inconsistency". All programming languages are equal up until the lack of tooling means that I need to tell someone to do a better job testing for nulls and side effects, even if the TDD community justifies my criticism by telling them that they should be doing just as good of a job as the computer, if only they were more diligent.