Comment by tomn

Comment by tomn 3 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).

danieldk 3 days ago

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.

Reply View 3 replies

tomn 3 days ago

> 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.

Reply View | 2 replies
- danieldk 3 days ago
  
  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.
  
  Reply View | 1 reply
  
  tomn 3 days ago
  
  > 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.
  Right, but even then the logical type for readFile would be something like "string -> string" (because from nix's perspective it is pure), but in haskell it would have to be "string -> IO string" (because from haskell's perspective it is not).
  Maybe this is fine, i just suspect it would make things messier than expected.
  Alternatively this could be worked around using unsafePerformIO or the FFI, but that feels a bit far away from the idea of just making a DSL? Unclear...
  > But I don't know why one would want to.
  Same, I just think it's an interesting discussion.
  
  Reply View | 0 replies

nothrabannosir 3 days ago

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.

Reply View 5 replies

tomn 3 days ago

> 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.

Reply View | 4 replies
- kstenerud 3 days ago
  
  > 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.
  
  Reply View | 2 replies
  
  tomn 3 days ago
  
  > 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)
  None of these are language problems, they are problems with the way nixpkgs is structured and the ways nix is used (or your understanding of those).
  Perhaps being purely functional causes some of this complexity/unfamiliarity, but in that case replacing it with another pure functional language (the original point i was replying to) is not going to help. Maybe replacing it with scheme (functional/imperative) does, I don't know.
  
  Reply View | 1 reply
  
  nothrabannosir 3 days ago
  
  The semantics of the language make it virtually impossible to write a good lsp with “go to definition”, particularly when you get into the module system (which is where you need it most). This is a massive barrier to entry and the only way to solve it is to spend a lot of time imbibing nix lore. It’s a fundamentally unsustainable language design for adoption as an incidental build tool and it’s no surprise that those who manage to persist are also the ones who spend a lot of time with it. Unlike a more ergonomic language with good tooling and semantics which encourage adoption by casual users.
  
  Reply View | 0 replies
- nothrabannosir 3 days ago
  
  Discourse is massive selection bias. The people who make it that far are not an accurate representation of the potential nix users.
  
  Reply View | 0 replies