λ IHP: Integrated Haskell Platform

Making haskell web apps is a complicated process. You need the right haskell compiler, a build tool, lots of libraries to do useful things and a database software. To make IHP as accessible as possible, we want to initially hide all this from the user. We set out to make IHP usable for people who have not yet heard about ghc and cabal.

Additionally when you are using an older compiler version, some library is missing or your postgres is not the right version this will cause trouble. Solving these package management issues is always a huge time sink.

Npm is mainly used for packaging javascript code. Composer is used for packaging php code. And homebrew is used for installing npm and composer ;) Nix is different: It is able to package system software and all kinds of software ecosystems. This is what allows us to bundle all the dependencies of IHP using just a single package manager. Exactly what we need to make a truly batteries-included framework.

Nix is unique in that it allows us to exactly specify the version of a package we want to install. We can say: Install the latest postgres 12.3. Nix also allows us to install packages locally for a specific project instead of managing all the dependencies system wide.

These two properties make nix a great fit to achive our goal of simplifying the package management process. Nix allows us to easily install all this software for developers working with IHP. We can install exactly the right compiler, the right postgres version as well as all the right libraries we need. We can be sure that all packages are installed in the right version (no time sinks!) and nothing is missing. We also don't have any interference with existing packages already installed on the system. It's like docker without the overhead of a VM.

The IHP dev server automatically starts and manages a postgres server in the background, just for your project. IHP is the first framework tighly integrating the database in the dev mode. We're sure that this will be standard in a couple of years. Without the possibilities of nix, we would have never tried to integrate postgres into the IHP dev server. The integrated database schema designer wouldn't really work that well. It might not be obvious, but without nix we would not have tools like the IHP schema designer or the database viewer.

Nix makes IHP projects reproducable in a way unseen in other software ecosystems. All IHP projects share exactly the same set of packages. The same compiler version, the same libraries, the same postgres version and even the same custom dependencies your app depends on. Works on my machine will not happen anymore. When there is a problem, other IHP users will most likely already have faced the same issue.

This is only possible because nix allows us to pin down the set of package definitions to a specific git commit of the nix package registry.

Nix is far from perfect. Early on we had a lot of problems with slow rebuild times, which we could resolve by using the great cachix binary cache. Additionally Nix is very hard to install. This is a stumbling block for a lot of people. Especially when using certain macOS systems you cannot even install nix at all. Luckily most of the nix problems, like the macOS issues will be solved with time.

Once nix is set up, it's usually working very well. Over time the benefits of nix really outweight the time spent on solving nix-specific problems. The rising industry adoption of Nix is a good indicator for this. Cool companies like Shopify are progressively adopting Nix.

At digitally induced we believe that highest quality software is built on solid foundations. Nix is technological superior to any other existing package manager. Therefore we believe it's right to make nix a hard requirement of IHP.