It is possible to “hash” a function so that the hash stays the same for as long as the function does the same thing (in which sense the language is similar to, e.g., Dhall), which is guaranteed because 1) function is pure, 2) the hash derives also from any other functions it may call and all the way down, and 3) everything is a function.
In the world of package management that gives you a superpower and/or curse of being able to say “I want dependency X” and mean “I want a dependency built in this exact way”. When applied thoroughly, the only inconsistencies in behavior that can arise in theory would be due to logic errors in external to Nix software or to hardware issues[0].
From provisioning deployed software runtime environments (in which sense Nix is more similar to, e.g., Docker) to automating your development machine configuration—basically anywhere you want consistency and hate surprises—in this sense Nix suffers from solving very different problems for different people, and as a result people being confused as to what is it for just by looking at articles and discussion threads about it.
[0] In practice, you might occasionally have to fight poorly behaved software that makes unwarranted assumptions about the system (can’t be installed into or look for dependencies under hash-paths), modifies itself (auto updates), etc.
It is possible to “hash” a function so that the hash stays the same for as long as the function does the same thing (in which sense the language is similar to, e.g., Dhall), which is guaranteed because 1) function is pure, 2) the hash derives also from any other functions it may call and all the way down, and 3) everything is a function.
In the world of package management that gives you a superpower and/or curse of being able to say “I want dependency X” and mean “I want a dependency built in this exact way”. When applied thoroughly, the only inconsistencies in behavior that can arise in theory would be due to logic errors in external to Nix software or to hardware issues[0].
From provisioning deployed software runtime environments (in which sense Nix is more similar to, e.g., Docker) to automating your development machine configuration—basically anywhere you want consistency and hate surprises—in this sense Nix suffers from solving very different problems for different people, and as a result people being confused as to what is it for just by looking at articles and discussion threads about it.
[0] In practice, you might occasionally have to fight poorly behaved software that makes unwarranted assumptions about the system (can’t be installed into or look for dependencies under hash-paths), modifies itself (auto updates), etc.