A lot of these selling points sound like features that Nix already has. What does Spack offer that Nix does not? Is it documentation? User experience? Wider support for computing libraries?
Co-author/spack guy/occasional frequenter of Nix fora here.
Aside from what p4ul said above, the main architectural differences between Nix and Spack are:
1. Spack has a dependency solver (the "concretizer"), Nix does not
2. Spack packages are parameterized, and we solve for parameters
like build options, compilers, virtual dependencies, etc.,
so the user can say what tweaks they want on the CLI or in
an environment. To do this same with Nix packages you typically need
to hack on some nixpkgs. The goal of Spack is to be able to compose
and swap libraries, compilers, and other options easily.
3. Spack has more support for external packages (or "impure" packages
as the Nix people say). You can point it at an existing installation
on your system to use as a dependency.
Hashing installation directories, the store-based installation model described in the paper are things the two have in common.
I'm not very familiar with Nix, but one rather unique feature of Spack is the concept of combinatorial builds.
Suppose we have a big HPC cluster, and suppose also that this is a fairly heterogeneous cluster in terms of CPU architectures. We might have, for example, 3 different generations of Intel chips. We would also have several different compilers, and several versions of MPI (e.g., OpenMPI, MVAPICH, etc.).
Using Spack, it is trivially simple to build a piece of software with all possible combinations of compiler-architecture-MPI.
Spack also integrates very nicely with LMOD, so managing Spack installs using the LMOD module system is extremely convenient.
I would also argue that the user experience with Spack is phenomenal, but that's just a personal preference.
