Agreed. For me it helped to think about how modules are composed--something about the order-invariance aspect of it made me understand why this was a good langu

Agreed. For me it helped to think about how modules are composed--something about the order-invariance aspect of it made me understand why this was a good language choice. Suppose you were actually using JSON. You've got X = {a:1, b:2} and Y = {b:3, c:4} In imperative land, if you start with X and then apply Y, "b" will be 3. And if you start with Y and then apply X "b" will be 2. That's bad if you're a package manager, you don't want the order that packages are installed to change their function. The imperative solution is to add some kind of metadata which indicates whether X and Y are compatible, and to consult some kind of solver which prevents you from even trying to do the thing that would create the order-dependence nightmare. But because of how the Nix language works, you never even get to the point where you're clobbering things. Nor do you have to consult a version solver. The fact that you've tried to make "b" both 2 and 3 is a language error. It's as close as you can get to making config errors syntactically invalid and helps you sidestep a whole domain of trouble. It also means that pretty much all problems are code problems, and that's a dimension that we know how to collaborate in. sorta.