9.2.8 is currently the recommended GHC in GHCup, but 9.2 branch won’t get a new release anymore.
Stackage LTS-21.1 has moved to 9.4.5: LTS Haskell 21.1 (ghc-9.4.5) :: Stackage Server
GHC developers expressed their feeling that 9.4.5 is a good release. It’s supported well by HLS too.
What are your opinions? Are there still libraries lacking for 9.4.5? Are companies using it yet? Is 9.2.8 more comfortable still?
I’ve been using GHC 9.4.5 since release, both at home and at work, and it’s been smooth sailing.
I would like to move the Stack project on to GHC 9.4.5, but I’m experiencing two sticking points on Alpine Linux/x86_64:
The GHC-supplied GHC 9.4.5 segfaults with Template Haskell - see #23043: Segmentation fault building package on alpine. · Issues · Glasgow Haskell Compiler / GHC · GitLab
The Nix-supplied GHC 9.4.5 segfaults with packages that rely on the hsc2hs that comes with it - see Changing pkgsMusl.haskell.compiler.ghc927 to .ghc945: segmentation fault with hsc2hs-created executable · Issue #239357 · NixOS/nixpkgs · GitHub
Stack uses Alpine Linux to build statically-linked Stack executables for use on Linux, so I’m keen to find solutions.
First of all… lots of upstream alpine bindists are in fact fully static GHC bindists. These cause all sorts of other issues as well. You don’t need a fully static GHC binary to build a fully static haskell executable.
That part is already communicated to GHC devs, but as a result, alpine bindists in ghcup are a bit flaky.
I’m open to building them manually. It sounded from the bug reports that using ld.bfd as linker might fix this? @bgamari
Are the guidelines that are used to determine recommendations for versions of each tool written down anywhere? (It might even be too fluid to commit to text). I’d love to be able to look up why a recommendation is the way it is at some point. I currently ignore the recommendations as I have no idea why they are what they are. For example I’ve had no negative consequences that I’m aware of for ignoring the seemingly stale cabal version recommendation, and I’ve been using GHC 9.4 for a while at home and work with little consequence, but presumably there’s a good reason for things to be held back for so long. It would be nice to be able to see that reason somewhere.
I did a little digging and found this issue as an example cabal 3.8 could get recommended perhaps? · Issue #40 · haskell/ghcup-metadata · GitHub . Unfortunately that issue was closed by the user rather than being preserved as a check-list of things that needed resolution before the recommendation could be advanced.
https://www.haskell.org/ghcup/install/#which-versions-get-installed
latest follows the latest release of every tool, while recommended is at the discretion of the GHCup maintainers and based on community adoption (hackage libraries, tools like HLS, stackage support, etc.) and known bugs.
Cabal 3.8 had a LOT of regressions. 3.10 is eyeballed for being recommended, but there’s still an unfortunate bug that is holding it back: Haddock for crypto-api-0.13.3 fails to build with Cabal 3.10.1.0 · Issue #9060 · haskell/cabal · GitHub
Haddock is core tooling, so we can’t have a half working haddock+cabal+ghc combination. And indeed, it appears bumping ghc recommended to 9.4 would “fix” this. But users who want to stay on 9.2 for some projects will still experience this.
Wrt documenting those things… I think the best way is in fact opening issues against ghcup-metadata repository and discuss it.
Some form of “community pressure” is in fact also part of the selection process. I kept 8.10.7 recommended for a very long time, because it was a great release and no one complained until fairly recently.
I think it’d be pretty neat to have such a ticket with links out to the reported issues that need to be resolved in order to justify a bump. The team clearly has an informed opinion about what they’re waiting for and seeing that listed out could inform people how they could help upstream, too.
That sounds like something a ghcup contributor could do.