The entire point of using NixOS is to modify text files that are then reflected in the OS configuration. There is a drawback. It’s called impedance mismatch. The analogy you want is object-relational impedance mismatch.
The entire point of Nix language is to streamline configuration by removing the need to memorize a bunch of stupid commands.
The Nix expression is not stateless. It represents a single state. You change the state by modifying the file. It is no different to have a program filter the file and modify it for you, to remove the need to do routine BS like running a hash function in a terminal. Do you really think the inventors of PHP were complaining about how HTML was “stateless”?
One of the primary attractions of functional languages is pattern matching. You’ve clearly missed a lecture about how pattern matching a syntax in Haskell is dramatically simpler than in C-like languages.
As I stated before, the field would be denoted by a special name, like
plaintext_password, and the field name would be replaced with one that is already supported by the Nix language, with the value replaced with the valid hashed password. It’s fool-proof.
The Nix language already has a syntax parser, so this modification sounds like a dead easy addition. The creators have already done the work of determining the context. All they have to do is add one more search string to match in the proper context. That’s it.
What are you even talking about? Every language worth its salt has multithreading and file I/O. The concepts of atomic editing are fully compatible with the concepts of multithreading. Each thread would be responsible for one atomic operation. Done in Haskell, the file IOs would be done on separate threads, even without using special syntax, if I am to believe that monads in fact allow otherwise impure processes to be treated as pure. Even if this isn’t done in Haskell, this could be done in virtually any language: C, Python, etc. with a threading library or built-in syntax.
Again, I would never have thought of such a convoluted implementation of such a simple idea. The plaintext password would be in the same place where the user is declared, not in a separate file on its own. You don’t need to do any mapping at all. I’m saying you can just separate the user declarations from the main configuration, so that the administrator doesn’t risk killing their main file, in the event that the program modifies the file containing the plain-text password. The logic is that, if the file doesn’t contain a match for the
plaintext_password field, it never needs to be opened as writable, thus not risking any corruption.