3 ms·
The main thing that made understanding the language much easier was the realization that you arent actually looking at imperative commands. Nix is just a big la
by JamesSwift 3y ago
The main thing that made understanding the language much easier was the realization that you arent actually looking at imperative commands. Nix is just a big lazily-evaluated JSON blob. All of the language is just commands to manipulate the values of that JSON. Once you understand that, I think its more straightforward (except some funky syntax like `//`)
- hiAndrewQuinn 3y agoThis is how I think of Dhall as well, which I highly recommend. https://dhall-lang.org/ https://dhall-lang.org/
- __MatrixMan__ 3y agoAgreed. 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.