What is the difference between Cabal and Stack?

Is stack a replacement for Cabal?

Yes and No.

In which cases should I use Stack instead of Cabal? What can Stack do that Cabal can’t?

Stack uses the curated stackage packages by default. That being so, any dependencies are known to build together, avoiding version conflict problems (which, back when they were commonplace in the Haskell experience, used to be known as “cabal hell”). Recent versions of Cabal also have measures in place to prevent conflict. Still, setting up a reproducible build configuration in which you know exactly what will be pulled from the repositories is more straightforward with Stack. Note that there is also provision for using non stackage packages, so you are good to go even if a package isn’t present in the stackage snapshot.

Personally, I like Stack and would recommend every Haskell developers to use it. Their development is fast. And it has a much better UX. And there are things which Stack does which Cabal yet doesn’t provide:

  • Stack even downloads GHC for you and keeps it in an isolated location.
  • Docker support (which is very convenient for deploying your Haskell applications)
  • Reproducible Haskell script: You can pinpoint version of a package and can get guarantee that it will always execute without any problem. (Cabal also has a script feature, but fully ensuring reproducibility with it is not quite as straightforward.)
  • Ability to do stack build --fast --file-watch. This will automatically rebuild if you change the local files present. Using it along with --pedantic option is a deal-breaker for me.
  • Stack supports creating projects using templates. It also supports your own custom templates.
  • Stack has built-in hpack support in it. It provides an alternative (IMO, a better) way of writing cabal files using yaml file which is more widely used in the industry.
  • Intero has a smooth experience when working with Stack.

There is a nice blog post explaining the difference: Why is Stack not Cabal? While Cabal has, in the intervening years since that post, evolved so as to overcome some of the issues discussed there, the discussion of the design goals and philosophy behind Stack remains relevant.

Leave a Comment