4 ms·

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

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.

throwaway894345 6y ago
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 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). But 100% agreement that Nix needs a type checker!
jcranmer 6y ago
Take this example build file in Mozilla's custom, Python-based build system: https://searchfox.org/mozilla-central/source/gfx/skia/moz.build https://searchfox.org/mozilla-central/source/gfx/skia/moz.bu... 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.
- takeda 6y ago
  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] [1] https://github.com/mozilla/nixpkgs-mozilla https://github.com/mozilla/nixpkgs-mozilla [2] https://github.com/mozilla/release-services https://github.com/mozilla/release-services
  - yjftsjthsd-h 6y ago
    > 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.
    - takeda 6y ago
      > 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.
      - throwaway894345 6y ago

throwaway894345 6y ago

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 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). But 100% agreement that Nix needs a type checker!

jcranmer 6y ago

Take this example build file in Mozilla's custom, Python-based build system: https://searchfox.org/mozilla-central/source/gfx/skia/moz.build https://searchfox.org/mozilla-central/source/gfx/skia/moz.bu... 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.

takeda 6y ago
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] [1] https://github.com/mozilla/nixpkgs-mozilla https://github.com/mozilla/nixpkgs-mozilla [2] https://github.com/mozilla/release-services https://github.com/mozilla/release-services
- yjftsjthsd-h 6y ago
  > 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.
  - takeda 6y ago
    > 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.
    - throwaway894345 6y ago