I think functional languages are a good fit for the problem though. Given some input, compute a static build plan. It's very rare that you need to do imperative-style computation for that. What I think Nix really needs is some kind of static typing, because right now if you make a type error the error might appear in a completely random location, making it difficult to debug.
I don't think this is any more true for this problem space than other problem spaces. The "pure functional package manager" property doesn't come from the functional expression language, but from the thing that takes the static build plan and executes it. You could make these build plans in Python (or Starlark https://go.starlark.net) very elegantly and with the massive added bonus that they are intelligible to a much broader audience, and Python still allows for a very functional style. The only caveat I would add is that the Nix expression language has really nice support for multiline strings and Python still hasn't figured that out. Lastly, Python also supports type annotations and even a type checker (although the type checker leaves a lot to be desired, such as basic types or callbacks that take kwargs so it might be better off to implement one's own type checker).
The language is imperative, and the result is fully declarative. A pure functional description of this logic would worsen understanding instead of improving it, I believe, because when your conditionals affect multiple output variables, you have to duplicate the condition in multiple places.
Looking at the code, I don't see any advantage of using imperative language here. All the conditions used there are already available and don't change during the execution of that code. So the conditionals would be nearly identical in functional language.
Nix advantage here would be that is lazily evaluated, so there would be an additional benefit that only conditionals that are used are evaluated.
Functional benefit of Nix would be that Nix would know that a package doesn't need to be rebuilt if no inputs changed.
Side note Mozilla actually uses Nix internally, it appears that it is used for Rust and Firefox and most likely other things[1][2]
> Looking at the code, I don't see any advantage of using imperative language here. All the conditions used there are already available and don't change during the execution of that code. So the conditionals would be nearly identical in functional language.
Yes, except that I can read this and I can't read nix. That's probably based on background, but more people are familiar with imperative than functional languages.
> Nix advantage here would be that is lazily evaluated, so there would be an additional benefit that only conditionals that are used are evaluated.
Agreed, although that's unlikely to be unique to nix?
> Functional benefit of Nix would be that Nix would know that a package doesn't need to be rebuilt if no inputs changed.
As would anything that can compare hashes. Or heck, make(1) can do as much.
> As would anything that can compare hashes. Or heck, make(1) can do as much.
Of course, language like Python is Turing Complete so you could implement the same functionality . You could also add functions that behave and perform operations lazily.
But you're missing the point though, those are properties that Nix provides natively that are tuned to what is required for this domain. Because the only side effect in nix is a derivation, and because language is lazily evaluated it is made for this purpose.
If you would use for example Python, you would need to write wrappers that would provide that behavior and it no longer would be Python, it would be some kind of DSL written in Python at that point and the risk then would be that it would be very easy to introduce iterative code that's not functional and not lazily evaluated (kind of like it happens with Chef recipes).
The Nix Language actually is not the problem here, the language is fairly simple, the biggest difficulty is actually nixpkgs which is huge and poorly documented. You often have to look at its code to understand what's going on. If it was written in Python you would have the same issues.
There is one thing that Nix Language could do better, a lot of people wish it was a typed language, because if it was typed it would be much easier to find a definitions, and wouldn't require as much of greping the code. But python again wouldn't help here.
Nix is also Turing complete, and Python (to my knowledge) can also run in a side-effect-free context through various methods (it’s easy enough to enforce during code review but there are technical solutions as well). There’s also Starlark which is a sealed, embedded Python-like which is NOT Turing complete and which can also avoid side effects (evaluating to a derivation, if you like).
Nix may be simple but it’s unfamiliar, and you’re already asking people to understand a novel package management system and everything about everything about their entire dependency tree, and these unknowns are collectively more confounding than the sum of their parts.
Python would help because it is familiar and gradually typed. That said, I’m open to any language that satisfies those properties (maybe also “composes nearly from expressions”).
I don't believe Nix is Turing complete, unless you include ability of running python or bash script.
Regarding the rest of your first paragraph, that's essentially what I said, you can write side effect free code in python, but it's so easy to introduce side effects if you're not paying attention.
I'm saying though that nix language isn't the hard part about nix, but perhaps you're right and it is one extra difficulty that just makes things harder.
But take a look at most o Nix derivations, majority of them end up being just an attribute set (aka dictionary, map etc in other languages)
Take look at https://nixos.org page (they changed it after this submission was posted, and it is better than the old page at showing what Nix can do)
