4 ms·

In the Nix language, which Guix takes heavy inspiration from (to say the least), there are a small handful of primitive types, but no mechanism for building up

In the Nix language, which Guix takes heavy inspiration from (to say the least), there are a small handful of primitive types, but no mechanism for building up bigger, more complex types. One of the primitive types is the derivation, which is not a set, not a list, not a number, etc. but a wholly new type which describes a package in the Nix store. I agree that Guix overcomplicates it, but they didn't have to. It's a natural consequence of using an incredibly powerful host language to embed their build language.

rekado 9y ago
Guix does not overcomplicate things. For example, it uses derivations exactly like those of Nix. (That's the extent to which Guix "takes heavy inspiration from" Nix: it uses the Nix daemon and thus the same derivation format.) G-expressions are used to generate build-side code without having to resort to ad-hoc string interpolation in a target language like Bash. Ideally, this could be done simply with quoted S-expressions, but the paper explains why S-expressions are a little too primitive to use them conveniently in this case. The gain here is that there is only one language and one set of rules for everything, namely Scheme. In Nix there is the Nix language and a mix of build-side languages (e.g. shell), where host-side values are embedded in build scripts through string interpolation. There's work underway to extend the reach of Scheme to the daemon itself.
- DonbunEf7 9y ago
  "Guix...uses the Nix daemon" and "to extend the reach of Scheme to the daemon" are incompatible and I hope you see why. Patches aren't flowing from Guix to Nix, or if they are, nobody's talking about it and the patches aren't showing up on anybody's radar. The wimpiness of the Nix language is a virtue. There is no call/cc. There's no ports, and indeed networking is tamed. The language is just barely powerful enough to do its job, and community members have found it somewhere between intractable and impossible to build compilers, text processors, etc. in Nix itself. String interpolation is a fitting punishment for our decision to continue to use Unix-styled systems; our systems think in bytes and communicate in bytes, and I see no reason why we should walk away from our highly-developed long-standing relationship with bytestrings as long as we are still on Unix. (You will say something beautiful about Scheme. I am busy looking ahead to capability-aware languages; Nix is a scaffold and nothing else.)
  - jancsika 9y ago
    > The wimpiness of the Nix language is a virtue. Why does there need to be a language? Why can't there just be something like a manifest in JSON?
    - benley 9y ago
      There can be, basically. But you often end up with huge repetitive mountains of JSON data, which isn't a ton of fun to maintain by hand, so then you write a tool to generate it from some other input data. Surprise, now you've invented a single-purpose DSL! What if you had a language that could serve as your input DSL, while remaining deterministic and still being flexible enough that you could skip the aforementioned dsl-to-json tool and just write that in the same config language? That's exactly what Nix is, along with some similar languages (Jsonnet, Dhall, Flabbergast, ...). They end up being useful as a way of generating whatever boilerplate or repetitive or obtuse input data you need to drive some system. Sure, you could do it in Python, but there's too many ways of doing non-deterministic non-hermetic things in a general-purpose language like that. Nix and Jsonnet and friends have no facilities for directly writing to disk, or talking to the network, or depending on some weird library being installed locally. They're just static configuration languages, and that can be extremely useful.
  - rekado 9y ago
    > "Guix...uses the Nix daemon" and "to extend the reach of Scheme to the daemon" are incompatible and I hope you see why. These are not incompatible statements. Guix uses an older version of the Nix daemon that has diverged from Nix mainline. As Schemers we prefer to hack on Scheme things, so we're halfway through writing the missing glue to use existing Scheme tools in place of the C++ daemon. > Patches aren't flowing from Guix to Nix They cannot because Guix is not a fork of Nix. Guix is an implementation of functional package management as pioneered by Nix. (As to your claims about Nix and Scheme: I'm not going to bite.)

rekado 9y ago

Guix does not overcomplicate things. For example, it uses derivations exactly like those of Nix. (That's the extent to which Guix "takes heavy inspiration from" Nix: it uses the Nix daemon and thus the same derivation format.) G-expressions are used to generate build-side code without having to resort to ad-hoc string interpolation in a target language like Bash. Ideally, this could be done simply with quoted S-expressions, but the paper explains why S-expressions are a little too primitive to use them conveniently in this case. The gain here is that there is only one language and one set of rules for everything, namely Scheme. In Nix there is the Nix language and a mix of build-side languages (e.g. shell), where host-side values are embedded in build scripts through string interpolation. There's work underway to extend the reach of Scheme to the daemon itself.

DonbunEf7 9y ago
"Guix...uses the Nix daemon" and "to extend the reach of Scheme to the daemon" are incompatible and I hope you see why. Patches aren't flowing from Guix to Nix, or if they are, nobody's talking about it and the patches aren't showing up on anybody's radar. The wimpiness of the Nix language is a virtue. There is no call/cc. There's no ports, and indeed networking is tamed. The language is just barely powerful enough to do its job, and community members have found it somewhere between intractable and impossible to build compilers, text processors, etc. in Nix itself. String interpolation is a fitting punishment for our decision to continue to use Unix-styled systems; our systems think in bytes and communicate in bytes, and I see no reason why we should walk away from our highly-developed long-standing relationship with bytestrings as long as we are still on Unix. (You will say something beautiful about Scheme. I am busy looking ahead to capability-aware languages; Nix is a scaffold and nothing else.)
- jancsika 9y ago
  > The wimpiness of the Nix language is a virtue. Why does there need to be a language? Why can't there just be something like a manifest in JSON?
  - benley 9y ago
    There can be, basically. But you often end up with huge repetitive mountains of JSON data, which isn't a ton of fun to maintain by hand, so then you write a tool to generate it from some other input data. Surprise, now you've invented a single-purpose DSL! What if you had a language that could serve as your input DSL, while remaining deterministic and still being flexible enough that you could skip the aforementioned dsl-to-json tool and just write that in the same config language? That's exactly what Nix is, along with some similar languages (Jsonnet, Dhall, Flabbergast, ...). They end up being useful as a way of generating whatever boilerplate or repetitive or obtuse input data you need to drive some system. Sure, you could do it in Python, but there's too many ways of doing non-deterministic non-hermetic things in a general-purpose language like that. Nix and Jsonnet and friends have no facilities for directly writing to disk, or talking to the network, or depending on some weird library being installed locally. They're just static configuration languages, and that can be extremely useful.
- rekado 9y ago
  > "Guix...uses the Nix daemon" and "to extend the reach of Scheme to the daemon" are incompatible and I hope you see why. These are not incompatible statements. Guix uses an older version of the Nix daemon that has diverged from Nix mainline. As Schemers we prefer to hack on Scheme things, so we're halfway through writing the missing glue to use existing Scheme tools in place of the C++ daemon. > Patches aren't flowing from Guix to Nix They cannot because Guix is not a fork of Nix. Guix is an implementation of functional package management as pioneered by Nix. (As to your claims about Nix and Scheme: I'm not going to bite.)