It’s been bad enough to make me not use Haskell for anything other than toying around. Of course, I understand that that’s not always an option.
I like the language, but the tooling around it is really, really brittle. Picking up Haskell code from a few years ago and getting it to compile has about a 10% change of success, even for relatively standard projects that “only” use a few outside dependencies.
Thanks for sharing! I have had the same experience, even using Nix for compilation, due to switching to Apple Silicon. I couldn’t build my blog for the longest time :(
Thanks to your comment, I went back, disabled the cabal config option, and it still works. I’d swear, though, that I had to do this… I’ve updated the blog post to reflect that this might not be necessary.
Thanks for writing this, @robertwpearce! While it’s always sad to read of experiences like yours, it is hard to improve if you don’t know how things fail.
There are a few reasons why we ask the user to install LLVM:
GHC’s AArch64 code generator was introduced in GHC 9.0; using any earlier compiler on M1 would require the use of the LLVM backend
The user may have pre-existing dotfiles which force the use of the LLVM backend
There are Hackage packages which (unfortunately, IMHO) force the use of the LLVM backend
Even with all the meta-tooling in place, building Haskell packages is an awful experience.
I’m curious! What’s your preferred method?
It’s been bad enough to make me not use Haskell for anything other than toying around. Of course, I understand that that’s not always an option.
I like the language, but the tooling around it is really, really brittle. Picking up Haskell code from a few years ago and getting it to compile has about a 10% change of success, even for relatively standard projects that “only” use a few outside dependencies.
I had the same conclusion even earlier that there isn’t really a there there.
Thanks for sharing! I have had the same experience, even using Nix for compilation, due to switching to Apple Silicon. I couldn’t build my blog for the longest time :(
To be fair, Apple Silicon is not a trivial change. Even nix can’t solve that since it’s a whole new CPU instruction set.
That said, Haskell is notorious for this. Only the node ecosystem is worse I think.
Yes! I hope I sounded like I was sharing an experience instead of being too critical. Thanks for sharing
Sounds like it’s hard to support two architectures with one GHCup.
Weird, I haven’t had to specify LLVM separately anywhere.
To confirm something: are you on Apple Silicon using ghcup? If so, how are you building projects?
Yes, M1 and ghcup. I use cabal, not stack. I have installed llvm and Xcode command line tools separately, but I didn’t have to tell cabal about llvm.
Thanks to your comment, I went back, disabled the cabal config option, and it still works. I’d swear, though, that I had to do this… I’ve updated the blog post to reflect that this might not be necessary.
Llvm is absolutely not needed. Recent ghc has a native arm code gen.
Source: I use ghc on m1. And help out making sure ghc on mac is great on and off over the years.
Hey, that’s great! If you have time, do you have the space to explain why GHCup’s installer says:
and why this error popped up during compilation?
Thanks for writing this, @robertwpearce! While it’s always sad to read of experiences like yours, it is hard to improve if you don’t know how things fail.
There are a few reasons why we ask the user to install LLVM:
This is such a helpful explanation—thank you for taking the time to write it.
I’m linking to your comment on the blog because of its great context!