Comment by tomn
4 days ago
> I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the similar lazy nature of the language.
My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by only the inputs), but whose implementation is very much not (it builds packages from a specification).
There may well be a work-around for that (it's been a while since i haskelled), but it's likely to end up with a result that's less clean than it would ideally be.
Personally I find the nix language to be a pretty good match for the tasks it is used for (though some basic static typing would be nice).
From the outside, i can see why it looks odd, but from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).
My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by only the inputs), but whose implementation is very much not (it builds packages from a specification).
Evaluation is completely pure (at least with flakes, which disallows querying environment variables, etc.). Evaluation of derivations will result in .drv files in the store, but that does not add impurity to the language itself. Building the .drv is a separate step (instantiation).
You could totally write something that generates .drv files in a different language and use Nix for instantiation (building). If I am not mistaken, this is how Guix started - they evaluated derivations defined in scheme to .drv files and then let the Nix daemon build them.
Aside from that, as a Nix user, I am happy that Haskell is not the language. Nix is a very small, simple language that is easy to wrap your head around and does not lead to a lot of abstractionitis. A want to say this in a way without painting a caricature, but the Haskell community has a tendency to pile on a lot of abstractions and I would hate to see a Nix with monad transformers, lenses, or whatever is popular these days.
> Evaluation is completely pure (at least with flakes, which disallows querying environment variables, etc.). Evaluation of derivations will result in .drv files in the store, but that does not add impurity to the language itself. Building the .drv is a separate step (instantiation).
If import-from-derivation is enabled (it normally is, it's a very useful feature, and the foundation of flakes), then some derivations need to be built to complete the evaluation.
https://nix.dev/manual/nix/2.25/language/import-from-derivat...
Even then functions like "readFile" are considered to be pure in nix, but not in haskell.
> If I am not mistaken, this is how Guix started - they evaluated derivations defined in scheme to .drv files and then let the Nix daemon build them
IIRC it still works that way; there's no real reason to change. Scheme isn't purely functional though (and the guix programming model is clearly imperative), so it doesn't have this mismatch.
If import-from-derivation is enabled
I have never looked at the implementation of IFD, but I assume that the evaluation and instantiation are still separated (and Nix will do multiple passes).
Even then functions like "readFile" are considered to be pure in nix, but not in haskell.
I am pretty sure that, unless you use --impure, all files that are read are required to be in the store. Since the store is read-only, it does not break purity.
At any rate, I agree that there will be some hoops to jump through. But I think it would be possible to make a Haskell DSL to define derivations similar to Nix. But I don't know why one would want to.
1 reply →
I don’t understand—the language itself is completely contained and separate from the derivation. Evaluation could be done in any language and the derivation will remain the output. You can absolutely have a better language generate derivations, surely? Hell, you could use Python typescript or go if you wanted to. They’d even be completely compatible with the unholy mess of cursed bash that is stdenv.
What you can’t port over to another language as neatly are the modules. Good riddance, id say. Undebuggable spaghetti from hell.
> from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).
Unfortunately I have wasted enough of my life to call myself “on the inside” and IMHO the language itself is close to the number one threat to wider adoption of nix.
> You can absolutely have a better language generate derivations, surely?
Yes, hence guix. The issue is that it doesn't fit well into a pure functional language like haskell if you want to allow import-from-derivation or basic functions like "readFile", without putting everything in IO (complicating the DSL).
https://nix.dev/manual/nix/2.25/language/import-from-derivat...
What you can’t port over to another language as neatly are the modules. Good riddance, id say. Undebuggable spaghetti from hell.
Not that it matters, but why not? Modules are written in the pure-functional bit of nix, so could be expressed in practically any language.
>> from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).
> Unfortunately I have wasted enough of my life to call myself “on the inside” and IMHO the language itself is close to the number one threat to wider adoption of nix.
I guess different people have different experiences. This was mainly based on my personal experience, but if you look through the help section on discourse, the questions are not about the language (at the time of writing i didn’t find even one in the first few pages):
https://discourse.nixos.org/c/learn/9
There also just doesn't seen to be a big push in the nix community to replace the language. Nickel exists, but i don't see the push for that from the nix side.
> but if you look through the help section on discourse, the questions are not about the language
Mostly because people don't know how to ask questions about the language. That was my experience.
Over the past decade I've made a few forays into Nix and NixOS (I still need to revert one of my servers back to Debian from NixOS). Inevitably I find the language obtuse, and the help online is always in the form of code fragments whose purpose kinda sorta looks alright maybe, but doesn't ever seem to fit into the setup I've built. So then I'm faced with completely rearranging the structure to match the helpful code, or try to massage the helpful code into my structure (which may or may not be a monstrosity, nor could I explain what every one of the magical incantations are for). Rinse and repeat with the next problem.
So it becomes essentially impossible to ask questions about it because I don't actually know where one thing ends and another begins.
After awhile, I start asking myself "Why was this a worthwhile venture again?"
I've heard good things about guix though. Might give that a try next. I'm done with Nix - burned one time too many.
2 replies →
Discourse is massive selection bias. The people who make it that far are not an accurate representation of the potential nix users.