Some other issues might be:
* The Prelude is hard to update for compatibility reasons, so it clashes with modern Haskell somewhat. A lot of projects will roll their own prelude and add 'NoImplicitPrelude' to the project options.
* There's also this presentation: https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why...
* Deploying Haskell programs to older corporate servers is doable, but not at all obvious. Stick with C, Bash, and older Perls(5.8.8 is on my router) for maximum portability, if you expect to deploy to servers with a 10 year old image.
What would be nice is if Haskell would allow any name collision so long as it could use the type system to disambiguate the function.
That would need very careful design to work well with type inference, I suppose?
Coincidentally, the reason why that practice is still visible in some C structures today is because very early C compilers had a similar limitation:
http://stackoverflow.com/questions/35874187/prefixes-in-memb...
You can build GHC with musl libc and then make truly portable static binaries but it isn't that easy.
https://www.reddit.com/r/haskell/comments/37m7q7/ghc_musl_ea...
https://github.com/mitchty/alpine-linux-ghc-bootstrap
Recently updated last week to 8.0.1, and its submitted upstream but not yet accepted because alpine linux 3.4 is about to come out.
If you want to try it now you can docker pull mitchty/alpine-ghc:8.0
I haven't tried building a statically linked musl ghc, and I honestly don't know how, but it'd be great to figure out. Any pointers? Speaking of static musl builds, that can be a good choice to create a single bindist of GHC that works on CentOS, Debian, Alpine, and any other Linux distro. Seeing how Docker defaults to Alpine images, it could be beneficial in that regard as well.
Presentation: https://secure.plaimi.net/~alexander/tmp/pres/2016-05-11-why...
EDIT: Also, if you find the colors on the slide show intolerable, the page source is well-formatted and readable. Content starts at line 200.