9 ms·

I've only tried Nix once or twice, and I'm left wondering: why don't they use a scripting language? Is part of the appeal that the Nix language is a functional

by nusaru 5y ago

I've only tried Nix once or twice, and I'm left wondering: why don't they use a scripting language? Is part of the appeal that the Nix language is a functional language?

darau1 5y ago
> tried Nix once or twice me too. I broke my system a bunch of times, and eventually just gave up. I remembered the other day that I have a lot of programs installed with it that I don't even want to think about updating. rofi changed it's configuration file format recently, and that was tied up in nix. I am too lazy to fight with it for now, so I've just disabled my config file. It bothers me every time I use it.
- lillecarl 5y ago
  NixOS is the only system I'm yet to break, and I've been using it at home for 2 years and at work full-time for a couple months. If the system evaluates it'll most likely work, if it doesn't you roll back a generation. I have an Ubuntu container around if I quickly wanna mess with something.
  - darau1 5y ago
    I'm positive it works. My problem was that figuring out why something went wrong was too time consuming, or difficult. I'm sure I could figure it out, but the problem again is time.
lillecarl 5y ago
So everything has to be pure and side-effect free, I'm not into the history and when you're not doing too much Voodoo it looks like what you'd want a configuration file to look like. But the downside is that debugging is impossble. Guix uses guile, which is a Lisp so we could accomplish the same with other languages.
microtonal 5y ago
why don't they use a scripting language Reproducibility. You need a pure (side effect-free) language to ensure that a package expression always evaluates to the same value [1]. If you have a non-pure language, external factors (e.g. environment variables or a server returning a different response) can influence/change what a package expression evaluates to. [1] That said, Nix was not completely free of side-effects either. Though this is one of the issues that Nix Flakes attempt to solve.
- CyberShadow 5y ago
  You can use pretty much any Turing complete language to achieve this constraint, as long as its inputs and execution are deterministic. The language itself doesn't have to be purely functional.
  - Filligree 5y ago
    The obvious choice is Haskell. It's a pity they didn't use that.
    - renox 5y ago
      Given that the alternative of Nix use a Lisp instead I'm not that sure of the 'obviousness' here..
    - flexagoon 5y ago
      Haskell is a general-purpose language, and Nix is made specifically for package management and system configuration. So Nix is significantly easier to learn than Haskell.
  - ImprobableTruth 5y ago
    ... and how do you ensure that it's execution is deterministic?
    - CyberShadow 5y ago
      Most programming languages are already generally deterministic. Pick any programming language. Now, remove access to I/O (except standard input and output), networking, time, random number generators, threads, OS syscalls, etc. Given an input, the program will always generate the same output, i.e. it is deterministic. However, the program is still allowed to have global mutable state; the state is just encapsulated to the program's memory and execution time. A trivial example is Brainfuck. It is most certainly not a functional programming language, but it is deterministic.
otabdeveloper4 5y ago
The Nix language is just JSON + lambda functions + variables. And nothing more. If you know modern JavaScript then you already know the Nix language. The problem is Nixpkgs, the largest Nix program. Nix-the-language doesn't lend itself too well to programming in the large. It's a bit like writing a large JavaScript SPA without frameworks or strict coding standards.
pxc 5y ago
As a longtime Nix user with very little prior FP experience (1/4 of one course in college doing a few exercises in Haskell), I think the Nix language is actually very well-suited to task. The biggest difficulty comes from the fact that it is a dynamic, weakly-typed language, which can lead error messages in configuration to point you toward library code rather than your config file. This is a pitfall shared by many of the languages that are commonly suggested as replacements or alternatives. There's been work to solve this by adding gradual typing (like in Typescript) to Nix, whose most promising iteration atm is (imo) a Nix-like language called Nickel, which is almost ready for preview by the community. The other, more minor, issue is tooling, which is being addressed by emerging LSP work for Nix. (Scripting is done in Nixpkgs, mostly via Bash.) The beauty of Nixlang, imo, is that for simple use cases it really feels like a dead simple configuration language, which is only possible with a declarative language. The functional character and Nix's laziness were important in the early design of Nix. The latter may still give Nix some nice performance characteristics. But since the initial Nix design, Nix has become eager in some places, and Guix is implemented as a lazy DSL embedded in an eager language, so I guess we could implement something like Nix on top of an eager scripting language. Imperative scripting languages might not be as well suited for the kinds of overrides that Nixpkgs and NixOS use, afaict. But imo aside from its novelty, the Nix language is nice to use because it's really simple and totally declarative, which is what you expect from a configuration language.
- rekado 5y ago
  I don't know what people consider "eager" in Guix. In the `package` DSL all input fields are thunked, so they are not eagerly resolved. You don't need all values of your language to have lazy semantics --- delaying evaluation of some values is enough. Just because Guile Scheme is no lazily evaluated by default does not mean that "Guix is eager" is a useful statement.
  - pxc 5y ago
    Thanks for the correction! > You don't need all values of your language to have lazy semantics Once upon a time (no longer, I think), Nix was 'maximally lazy', so I think historically at least, there has been a question of how essential laziness is to the design of package managers in the functional paradigm. Since then I guess we've seen what you describe (some targeted laziness) is all that's required in both DSLs. I've edited my comment above to better reflect Guix's design and stop spreading the 'Guix is eager' meme. :)

by nusaru 5y ago

I've only tried Nix once or twice, and I'm left wondering: why don't they use a scripting language? Is part of the appeal that the Nix language is a functional language?

darau1 5y ago

> tried Nix once or twice me too. I broke my system a bunch of times, and eventually just gave up. I remembered the other day that I have a lot of programs installed with it that I don't even want to think about updating. rofi changed it's configuration file format recently, and that was tied up in nix. I am too lazy to fight with it for now, so I've just disabled my config file. It bothers me every time I use it.

lillecarl 5y ago
NixOS is the only system I'm yet to break, and I've been using it at home for 2 years and at work full-time for a couple months. If the system evaluates it'll most likely work, if it doesn't you roll back a generation. I have an Ubuntu container around if I quickly wanna mess with something.
- darau1 5y ago
  I'm positive it works. My problem was that figuring out why something went wrong was too time consuming, or difficult. I'm sure I could figure it out, but the problem again is time.

lillecarl 5y ago

So everything has to be pure and side-effect free, I'm not into the history and when you're not doing too much Voodoo it looks like what you'd want a configuration file to look like. But the downside is that debugging is impossble. Guix uses guile, which is a Lisp so we could accomplish the same with other languages.

microtonal 5y ago

why don't they use a scripting language Reproducibility. You need a pure (side effect-free) language to ensure that a package expression always evaluates to the same value [1]. If you have a non-pure language, external factors (e.g. environment variables or a server returning a different response) can influence/change what a package expression evaluates to. [1] That said, Nix was not completely free of side-effects either. Though this is one of the issues that Nix Flakes attempt to solve.

CyberShadow 5y ago
You can use pretty much any Turing complete language to achieve this constraint, as long as its inputs and execution are deterministic. The language itself doesn't have to be purely functional.
- Filligree 5y ago
  The obvious choice is Haskell. It's a pity they didn't use that.
  - renox 5y ago
    Given that the alternative of Nix use a Lisp instead I'm not that sure of the 'obviousness' here..
  - flexagoon 5y ago
    Haskell is a general-purpose language, and Nix is made specifically for package management and system configuration. So Nix is significantly easier to learn than Haskell.
- ImprobableTruth 5y ago
  ... and how do you ensure that it's execution is deterministic?
  - CyberShadow 5y ago
    Most programming languages are already generally deterministic. Pick any programming language. Now, remove access to I/O (except standard input and output), networking, time, random number generators, threads, OS syscalls, etc. Given an input, the program will always generate the same output, i.e. it is deterministic. However, the program is still allowed to have global mutable state; the state is just encapsulated to the program's memory and execution time. A trivial example is Brainfuck. It is most certainly not a functional programming language, but it is deterministic.

otabdeveloper4 5y ago

The Nix language is just JSON + lambda functions + variables. And nothing more. If you know modern JavaScript then you already know the Nix language. The problem is Nixpkgs, the largest Nix program. Nix-the-language doesn't lend itself too well to programming in the large. It's a bit like writing a large JavaScript SPA without frameworks or strict coding standards.

pxc 5y ago

As a longtime Nix user with very little prior FP experience (1/4 of one course in college doing a few exercises in Haskell), I think the Nix language is actually very well-suited to task. The biggest difficulty comes from the fact that it is a dynamic, weakly-typed language, which can lead error messages in configuration to point you toward library code rather than your config file. This is a pitfall shared by many of the languages that are commonly suggested as replacements or alternatives. There's been work to solve this by adding gradual typing (like in Typescript) to Nix, whose most promising iteration atm is (imo) a Nix-like language called Nickel, which is almost ready for preview by the community. The other, more minor, issue is tooling, which is being addressed by emerging LSP work for Nix. (Scripting is done in Nixpkgs, mostly via Bash.) The beauty of Nixlang, imo, is that for simple use cases it really feels like a dead simple configuration language, which is only possible with a declarative language. The functional character and Nix's laziness were important in the early design of Nix. The latter may still give Nix some nice performance characteristics. But since the initial Nix design, Nix has become eager in some places, and Guix is implemented as a lazy DSL embedded in an eager language, so I guess we could implement something like Nix on top of an eager scripting language. Imperative scripting languages might not be as well suited for the kinds of overrides that Nixpkgs and NixOS use, afaict. But imo aside from its novelty, the Nix language is nice to use because it's really simple and totally declarative, which is what you expect from a configuration language.

rekado 5y ago
I don't know what people consider "eager" in Guix. In the `package` DSL all input fields are thunked, so they are not eagerly resolved. You don't need all values of your language to have lazy semantics --- delaying evaluation of some values is enough. Just because Guile Scheme is no lazily evaluated by default does not mean that "Guix is eager" is a useful statement.
- pxc 5y ago
  Thanks for the correction! > You don't need all values of your language to have lazy semantics Once upon a time (no longer, I think), Nix was 'maximally lazy', so I think historically at least, there has been a question of how essential laziness is to the design of package managers in the functional paradigm. Since then I guess we've seen what you describe (some targeted laziness) is all that's required in both DSLs. I've edited my comment above to better reflect Guix's design and stop spreading the 'Guix is eager' meme. :)