Qualitative analysis of 2022 survey results

This is the sixth year that I have conducted the annual state of Haskell survey. I recently posted the raw results, including charts of responses and JSON or CSV downloads:

I consider that a quantitative analysis. It’s just the numbers but no commentary. I used to provide commentary when I published the results. I don’t do that anymore because people are eager to see the results and it takes a while to write the commentary. So this year I decided to write up a qualitative analysis here.

I’m not going to review every single question. Instead I’m going to focus on the ones that are interesting to me, either in isolation or as a trend. If you don’t see a question here, chances are its responses are basically the same as previous years.


Fewer people responded to the survey this year than any previous year. It certainly looks like a downward trend, but I’m not sure what that means. Some charitable explanations are that people are simply tired of taking the survey, or I didn’t do as good a job of advertising it this year.


GHCJS usage has been remarkably consistent through the years, but this year it fell from 8% to 5% of respondents. I don’t personally use GHCJS, so this is wild speculation, but I think two things contributed to this: GHCJS is stuck on an older version of GHC, and soon GHCJS will be integrated into GHC itself. I think many people are in a “wait an see” situation where they may start using GHCJS if it’s part of GHC, otherwise they’ll avoid it because they don’t want to be stuck on an old version of the compiler.


As a tool for installing GHC, Stack has been steadily losing ground to both Nix and GHCup. This year was the first time that it wasn’t in the #1 spot. In fact it fell all the way to #3! I see this as a huge win for GHCup. Kudos to @hasufell for developing such a great tool!


Upgrading GHC broke more code this year than any previous year. The causes haven’t changed: incompatible dependencies and expected changes (such as the now-ancient MonadFail proposal). This certainly matches my experience where normally I upgrade to the latest GHC quickly, but this year getting to 9.2 and 9.4 proved to be a challenge. I think there were many major changes to GHC that contributed to this, such as better support for ARM64.


(I apologize for the weird chart. This is a hard one to visualize.) Usually the bulk of respondents use the three latest major versions of GHC. For example in 2020 most people used 8.10.x, 8.8.x, or 8.6.x. This is hard to compare year to year because GHC’s release schedule isn’t calendar based. For example in 2021, version 9.2.1 of GHC was released just days before the survey went out.

Anyway, the interesting this this year is that many people are still using GHC 8.10.x. This is the first time I’ve seen a distribution like this. Perhaps it relates to the previous question, where upgrading to GHC 9.0.x (or 9.2.x or 9.4.x) would cause too much breakage.


(The dip in 2020 is due to a bug in the survey.) Much like GHC installation methods, Stack has been losing ground. Last year was the first time Cabal overtook Stack, and that trend continues.

Thanks for reading! I hope that was interesting. Let me know what you think about this analysis, and what observations you made as well!


Some charitable explanations are that people are simply tired of taking the survey, or I didn’t do as good a job of advertising it this year.

I think it’s a shift to rust, with limited time in the day, people use rust at work and don’t have time to continue using haskell at night. This is complete speculation.

1 Like

We discussed that with community and came up with following statements about the attached question.

  • While earlier Stackage was the package source for Stack, it’s not the case anymore.
  • And I mean that right now stack is using Stackage indirectly (in context of “package sources”): to resolve build plan, to get info for specific package based on resolver, etc.
  • We remember times when builds were failing due to AWS subnet bans (Stackage was unavailable but Hackage was available).
  • I think, since casa there was a shift from Stackage to Hackage as main source of packages.
  • However, if for some reason Hackage is unavailable, stack will fall back to Stackage (since it’s not only a packages set but also a Hackage mirror).

The similar situation is about Nix.

  • Pre-built dependencies could be retrieved from cache.nixos.org.
  • Meantime, when it’s not a case, nix could still use either Hackage or source repository (it depends on package configuration).
1 Like