At work (Groq) we recently upgraded the version of GHC that we use from 8.10 to 9.6, along with many of the Haskell packages we depend on. I’ve written an article with details of the the breaking changes we had to deal with during that process.
Thanks for publishing this!
You didn’t report your impression, so I’m curious to learn about it. Simon Marlow once mentioned that GHC upgrades at Meta take on the order of person-years of work. Did you have a similar experience?
P.S. I’m curious about how Groq uses Haskell. Is it used for ASIC synthesis?
2 Likes
We have a bit over 200k lines of Haskell and it didn’t take us person-years. I think person-month is the rough order of magnitude. I guess Meta has a lot more Haskell code though.
Groq uses Haskell for part of the compilation pipeline (what’s called the assembler), a custom build infrastructure (on top of Nix), and some hardware design tooling and verification. We also heavily use C++, Python and System Verilog.
4 Likes
Thanks for this @tomjaguarpaw, it’s useful to have some evidence about where upgrade costs are arising. It generally confirms my impression that the main challenge is around library version changes rather than GHC itsel.
You mention simplified subsumption as an issue, with the “breaking fix” of enabling DeepSubsumption. But isn’t DeepSubsumption used by default when the base language edition is Haskell98 or Haskell2010, which were the only options prior to GHC 9.2 anyway? So I think code implicitly relying on deep subsumption should continue to work in GHC versions that support DeepSubsumption, unless you also enable to GHC2021 at the same time? (I suppose there were a few intermediate versions where that wasn’t the case, at least in the 9.2.x series.)
Otherwise, apart from one clear bug, the other GHC-related issues seem to be changes in warnings, in some cases providing advance notice of forward-compatibility issues without breaking code.
2 Likes
Yes, I think that’s right, and that’s been my impression until now, at least from my breakage inventories of 9.8 and 9.10.
Interesting! But we don’t build with cabal (rather with Nix) so I don’t think any language version explicitly gets set and therefore we just pick up whatever is the default language version (for 9.6 presumably that’s GHC2021).
You should probably consider setting an explicit language version to avoid breakage due to the default language version changing. From the discussion on this around GHC2024 it seems there is consensus that the default language version is to be changed regularly.
11 Likes
Yes! GHC’s stability goal is that if you compile the same program with the same language edition and same extension flags, it should still work. It is not a goal that the same program should work with a new language edition.
Setting your language edition explicitly is highly recommended.
14 Likes
Given that PackageImports is about to get deprecated, but the cryptonite→crypton transition is still in progress, I wonder whether you have these two packages co-exist on GHC 9.6? Since nixpkgs is applying unmerged patches, I wonder whether you’re using Nix to force packages onto crypton?
I don’t believe we use cryponite or crypton.