10 ms·

I much prefer GNU Guile over Nix. Anyone else? I saw some progress being made towards making NixOS compatible with other programming languages.

bjoli 3y ago
Well. One is a language that has metasyntactic abilities and a decent standard library. One is not. Defining a package in guix is a lot nicer than in nix
cmm 3y ago
I find Nix to be very close to the perfect DSL for what it does, and I like it quite a lot. But then I never bothered to look at Guix closely -- is its DSL at least lazy? Are there any honest comparisons wrt verbosity and awkwardness of Nix and Guix for stuff both are supposed to be good at? No idea what "making NixOS compatible with other programming languages" is supposed to mean. On the face of it the phrase is, well, baffling. Would you care to elaborate?
- medo-bear 3y ago
  Guix uses Guile, which is a general purpose scheme/lisp dialect, allowing for lazy evaluation
  - cmm 3y ago
    I know quite well what Guile and Scheme are; I was asking about the specific DSL/library/whatever combo that Guix is programmed in. The code snippets on the page which this thread is about, for example, mostly use macros that seem to mimic their Nix equivalents very closely but are marginally more verbose. I would very much like to see a compelling example where the fact that Guile has macros makes a practical difference. (Note that Nix's laziness is not an unalloyed good either, for example it is notoriously difficult to debug. But let's limit ourselves to pure expressiveness for now)
    - medo-bear 3y ago
      Well I mean look at the docs. To each their own but I find Guile much more palatable than Nix. Moreover, I would rather spend time learning Guile than an obscure language like Nix. But for you Nix is a perfect DSL so i think we would probably be bashing our heads against the wall debating which is better. As regards macros, Guile allows you to write your own macros in a pretty straight forward way that is just not the case in Nix
      - cmm 3y ago
        I'm not trying to "debate" anything here. I do note that those Guix people that are feeling competitive towards Nix for whatever reason tend to over-rely on two arguments that just do not work too well when examined closely. The first is "Nix is obscure the way Guile is not". I would argue both are equally obscure and neither is obscure enough for its quality or UX to suffer for it. And does expertise in Guile (base Scheme is trivial) carry over anywhere interesting? The second is "Macros!", where the implied idea is that unrestricted syntactic extensibility is Good. Well, I like Lisp (more partial to CL then Scheme, but who cares at this resolution), and I find unrestricted syntactic extensibility to be more of a hazard than a benefit; plus the expressivity of a non-strict FP language really gets you close enough for practical purposes.
        medo-bear 3y ago
        Besider Guix, Guile is also the default extension language for the GNU project. Moreover by learning Guile you learn a lisp which some people find quite enlightening. What do you gain from learning Nix, asside from Nix? Moreover, "macros are good" in the sense that they are powerful and grant the user freedom to construct software in ways that are just not possible with languages that try to herd their users into a specific mode of behavioir. It is the old freedom and responsibility problem. Again, I believe it is a matter of choice and personal preference
        cmm 3y ago
        Oh boy. > Guile is also the default extension language for the GNU project. AFAIK Guix is the only project that uses Guile and has any actual users (I'm not counting Shepherd because outside GuixSD it is nothing). Guile is like 30 years old, and has been envisioned as "the default extension language for the GNU project" all that time (I was an active contributor for a while, so I should know). Guile is not even used by Emacs; Guile extensibility support in GDB is not even commonly built by distros. Guile is a nice and very competent Scheme implementation and I'd love for it to be useful outside Guix, but that's just not the case, and repeating that slogan won't change it. Seriously, just stop. > It is the old freedom and responsibility problem No, it is not. Software development is a social and technical field, not a branch of philosophy.
- rekado 3y ago
  > its DSL at least lazy This keeps getting asked and it's baffling to me. Any programming language can delay evaluation by wrapping values in thunks where that makes sense, so it seems odd to me to give so much importance to whether values are evaluated strictly or delayed by default. Guix package definitions declare other package values as inputs, and evaluation of these inputs is in fact delayed. Verbosity: in Guix we don't generally run shell snippets as part of a build; the build phases are compiled into a Guile builder script, so in the absence of helpful abstractions build phases do not generally have the conciseness of shell scripts. On the other hand abstractions are easily fashioned, so some things are more concise and clearer than the shell equivalent.
  - cmm 3y ago
    > Any programming language can delay evaluation by wrapping values in thunks where that makes sense Indeed. I was simply asking whether the macros used for programming Guix are lazy, how is that baffling?
    - rekado 3y ago
      It's baffling because the question is too vague to produce a meaningful answer. What does it mean for macros in Guix to be lazy? The expansion of some macros may be (and is) lazy. For some things lazy evaluation is sensible (e.g. for declaring dependencies because you don't necessarily want to go evaluate the whole graph whenever you evaluate a single package value), for others it is not.
  - ParetoOptimal 3y ago
    > > its DSL at least lazy > This keeps getting asked and it's baffling to me. Any programming language can delay evaluation by wrapping values in thunks where that makes sense, so it seems odd to me to give so much importance to whether values are evaluated strictly or delayed by default. At least in Haskell laziness increases composability. I can't think of any examples in Nix, but maybe it's the same reason?
    - t0astbread 3y ago
- civodul 3y ago
  One thing that's often overlooked with Nix (the language) is that it does not let you define new data types. For example, there's no "package" type in Nix and Nixpkgs; instead there are only functions that are passed "attribute sets" (key/value dictionaries). That Nix can't tell what's a package and what's not is a hindrance for its user interface (e.g., it's hard to look up packages by name/version or to iterate over them) and for packagers (e.g., easy to end up with package definitions that don't follow the informal "schema").
- mongol 3y ago
  This presentation I think was a fair attempt to compare, or at least to look at Guix from a Nix perspective https://youtu.be/bDGzCXr6VYU https://youtu.be/bDGzCXr6VYU
pmoriarty 3y ago
I'm in love with Scheme, so would much rather use Guile/Guix for this than learn Nix's DSL that's not even lispy and that's not used anywhere else.
- Filligree 3y ago
  These days those aren't the only options; you can also use Nickel: https://github.com/nickel-lang/nickel-nix https://github.com/nickel-lang/nickel-nix Which isn't fully baked, no, but here's hoping.
ducktective 3y ago
I think with the introduction of Nickel [1], Nix packages would be rewritten in it over time, which may be a good thing (types) or a bad thing (another fragmentation after flakes) depending on your point of view. On the other hand, Guile is not a DSL but a general purpose language or a Lisp (Scheme to be exact), so it's not actually a downside compared to a DSL in my view. I myself am torn between these two. Nix community is larger and they have more packages. Guix, being a GNU project, obsessing over ""non-free"" sure won't help in its adoption. Even debian folks toned down their stance on this, why couldn't Guix do so too? [1]: https://github.com/tweag/nickel https://github.com/tweag/nickel
- rekado 3y ago
  > Guix, being a GNU project, obsessing over nON-fReE As a long time contributor to Guix I find that the "obsessing" is regularly done by others when talking about GNU. There's enough useful free software out there that needs packaging, and that's what I do. I don't need the extra headache of special snowflake licenses or custom restrictions. For nonfree software that doesn't have a popular alternative I contribute to guix-science-nonfree. It's barely an inconvenience for users to expressly add another channel to their Guix installation.
  - accelbred 3y ago
    When I used Guix, I needed nonfree for Firefox and the upstream Linux kernel. I also prefer to only use free software, and also like them not including proprietary software. Needing a channel was a huge inconvenience as you would often pull your channels and stuff would break, as guix was updated but non-guix wasn't. Managing channel manifests was a pain. Firefox would often be months out of date as well. Moved to NixOS, didn't enable allowUnfree, and had an actually up to date and simple to maintain system. Flakes solves the channels problems too. I had put a lot of effort into making Guix work, but it just had too many usabiltity issues, and the policy on firefox was a major one.
    - davexunit 3y ago
      Counter anecodate: I use guix + the nonguix channel for firefox, linux, etc. and it has been smooth sailing for quite some time.
grumbel 3y ago
Opposite for me. Nix syntax is much more pleasant to use and while Nix error messages are by no means perfect, still more fun than digging through multiple layers of Scheme. Does Guix have anything similar to Nix flakes yet?
- civodul 3y ago
  I believe the use of Guix channels shown in the article is comparable to Flakes.
  - grumbel 3y ago
    From what I understand, channels can be used to extend Guix, but don't quite work like Flakes, more like the old Nix channels. The thing that makes Flakes special is that they allow you to treat Git repositories like software packages. No more need for a distribution to package the software, you can just drop a 'flake.nix' file into the Git repository and that makes it behave like a package that users can install and other Flakes can depend on. I am really fond of the ability to just run software straight from Git, e.g.: nix run github:ggerganov/llama.cpp Makes it really easy to switch versions, fork, patch or otherwise customize things.
    - rekado 3y ago
      The blog post in this submission makes the same point: a git repo can be a channel, you just need to add a file for it.
rowanG077 3y ago
I personally prefer Nix greatly it's just JSON with functions basically. I just find Guile expressions totally unreadable with the brackets everywhere.
- gglitch 3y ago
  Genuine question, not trying to create or sustain a debate: are there more brackets in scheme than in json? I don't use json much, but the example I find in the "Syntax" section of the Wikipedia article on json [0], looks almost identical to how I'd structure the same data in Scheme, though with more quotation marks [1]. Is this just a bad example? [0] - https://en.wikipedia.org/wiki/JSON#Syntax https://en.wikipedia.org/wiki/JSON#Syntax [1] - Edit: more quotation marks, commas, and colons
  - grumbel 3y ago
    The difference is that name/value pairs have a dedicated syntax in JSON and Nix, in Scheme everything is (), doesn't matter if it's a function call, list, assignment, macro or whatever. Makes it very hard to understand what is going on at first glance. Worse yet, the normal Scheme syntax is so ugly that people constantly write macros to hide it. Take this package definition in Guix: (package ... (build-system gnu-build-system) (arguments '(#:configure-flags '("--enable-silent-rules"))) (inputs (list gawk)) Looks like a list with name/value pairs, but it's not, that's just the (package)-macro making that thing behave that way. And it's all quite arbitrary, '#:configure-flags' there is a name/value list too, but constructed completely differently. And the next line with (inputs) constructs a list with (list) instead of with a ' quote, as otherwise the list would contain the symbol 'gawk' instead of the value. Scheme is basically: "Here is the a bunch of Lego, go build yourself a programming language". Other language have syntax that forces at least a minimum of consistency.
  - rowanG077 3y ago
    It's about specialization. In JSON brackets have dedicated meaning. In scheme it's () galore. And () doesn't give me any meaning of what's actually there. Not that JSON or the Nix language is perfect, or even good, but this point makes it a lot better then a Lisp for me. Essentially quickly scanning over lisp code doesn't give me any inclination about the structure at all, which I think is very important. I admit I haven't written a ton of lisp so maybe that's the problem.

bjoli 3y ago

Well. One is a language that has metasyntactic abilities and a decent standard library. One is not. Defining a package in guix is a lot nicer than in nix

cmm 3y ago

I find Nix to be very close to the perfect DSL for what it does, and I like it quite a lot. But then I never bothered to look at Guix closely -- is its DSL at least lazy? Are there any honest comparisons wrt verbosity and awkwardness of Nix and Guix for stuff both are supposed to be good at? No idea what "making NixOS compatible with other programming languages" is supposed to mean. On the face of it the phrase is, well, baffling. Would you care to elaborate?

medo-bear 3y ago
Guix uses Guile, which is a general purpose scheme/lisp dialect, allowing for lazy evaluation
- cmm 3y ago
  I know quite well what Guile and Scheme are; I was asking about the specific DSL/library/whatever combo that Guix is programmed in. The code snippets on the page which this thread is about, for example, mostly use macros that seem to mimic their Nix equivalents very closely but are marginally more verbose. I would very much like to see a compelling example where the fact that Guile has macros makes a practical difference. (Note that Nix's laziness is not an unalloyed good either, for example it is notoriously difficult to debug. But let's limit ourselves to pure expressiveness for now)
  - medo-bear 3y ago
    Well I mean look at the docs. To each their own but I find Guile much more palatable than Nix. Moreover, I would rather spend time learning Guile than an obscure language like Nix. But for you Nix is a perfect DSL so i think we would probably be bashing our heads against the wall debating which is better. As regards macros, Guile allows you to write your own macros in a pretty straight forward way that is just not the case in Nix
    - cmm 3y ago
      I'm not trying to "debate" anything here. I do note that those Guix people that are feeling competitive towards Nix for whatever reason tend to over-rely on two arguments that just do not work too well when examined closely. The first is "Nix is obscure the way Guile is not". I would argue both are equally obscure and neither is obscure enough for its quality or UX to suffer for it. And does expertise in Guile (base Scheme is trivial) carry over anywhere interesting? The second is "Macros!", where the implied idea is that unrestricted syntactic extensibility is Good. Well, I like Lisp (more partial to CL then Scheme, but who cares at this resolution), and I find unrestricted syntactic extensibility to be more of a hazard than a benefit; plus the expressivity of a non-strict FP language really gets you close enough for practical purposes.
      - medo-bear 3y ago
        Besider Guix, Guile is also the default extension language for the GNU project. Moreover by learning Guile you learn a lisp which some people find quite enlightening. What do you gain from learning Nix, asside from Nix? Moreover, "macros are good" in the sense that they are powerful and grant the user freedom to construct software in ways that are just not possible with languages that try to herd their users into a specific mode of behavioir. It is the old freedom and responsibility problem. Again, I believe it is a matter of choice and personal preference
        cmm 3y ago
        Oh boy. > Guile is also the default extension language for the GNU project. AFAIK Guix is the only project that uses Guile and has any actual users (I'm not counting Shepherd because outside GuixSD it is nothing). Guile is like 30 years old, and has been envisioned as "the default extension language for the GNU project" all that time (I was an active contributor for a while, so I should know). Guile is not even used by Emacs; Guile extensibility support in GDB is not even commonly built by distros. Guile is a nice and very competent Scheme implementation and I'd love for it to be useful outside Guix, but that's just not the case, and repeating that slogan won't change it. Seriously, just stop. > It is the old freedom and responsibility problem No, it is not. Software development is a social and technical field, not a branch of philosophy.
rekado 3y ago
> its DSL at least lazy This keeps getting asked and it's baffling to me. Any programming language can delay evaluation by wrapping values in thunks where that makes sense, so it seems odd to me to give so much importance to whether values are evaluated strictly or delayed by default. Guix package definitions declare other package values as inputs, and evaluation of these inputs is in fact delayed. Verbosity: in Guix we don't generally run shell snippets as part of a build; the build phases are compiled into a Guile builder script, so in the absence of helpful abstractions build phases do not generally have the conciseness of shell scripts. On the other hand abstractions are easily fashioned, so some things are more concise and clearer than the shell equivalent.
- cmm 3y ago
  > Any programming language can delay evaluation by wrapping values in thunks where that makes sense Indeed. I was simply asking whether the macros used for programming Guix are lazy, how is that baffling?
  - rekado 3y ago
    It's baffling because the question is too vague to produce a meaningful answer. What does it mean for macros in Guix to be lazy? The expansion of some macros may be (and is) lazy. For some things lazy evaluation is sensible (e.g. for declaring dependencies because you don't necessarily want to go evaluate the whole graph whenever you evaluate a single package value), for others it is not.
- ParetoOptimal 3y ago
  > > its DSL at least lazy > This keeps getting asked and it's baffling to me. Any programming language can delay evaluation by wrapping values in thunks where that makes sense, so it seems odd to me to give so much importance to whether values are evaluated strictly or delayed by default. At least in Haskell laziness increases composability. I can't think of any examples in Nix, but maybe it's the same reason?
  - t0astbread 3y ago
civodul 3y ago
One thing that's often overlooked with Nix (the language) is that it does not let you define new data types. For example, there's no "package" type in Nix and Nixpkgs; instead there are only functions that are passed "attribute sets" (key/value dictionaries). That Nix can't tell what's a package and what's not is a hindrance for its user interface (e.g., it's hard to look up packages by name/version or to iterate over them) and for packagers (e.g., easy to end up with package definitions that don't follow the informal "schema").
mongol 3y ago
This presentation I think was a fair attempt to compare, or at least to look at Guix from a Nix perspective https://youtu.be/bDGzCXr6VYU https://youtu.be/bDGzCXr6VYU

pmoriarty 3y ago

I'm in love with Scheme, so would much rather use Guile/Guix for this than learn Nix's DSL that's not even lispy and that's not used anywhere else.

Filligree 3y ago
These days those aren't the only options; you can also use Nickel: https://github.com/nickel-lang/nickel-nix https://github.com/nickel-lang/nickel-nix Which isn't fully baked, no, but here's hoping.

ducktective 3y ago

I think with the introduction of Nickel [1], Nix packages would be rewritten in it over time, which may be a good thing (types) or a bad thing (another fragmentation after flakes) depending on your point of view. On the other hand, Guile is not a DSL but a general purpose language or a Lisp (Scheme to be exact), so it's not actually a downside compared to a DSL in my view. I myself am torn between these two. Nix community is larger and they have more packages. Guix, being a GNU project, obsessing over ""non-free"" sure won't help in its adoption. Even debian folks toned down their stance on this, why couldn't Guix do so too? [1]: https://github.com/tweag/nickel https://github.com/tweag/nickel

rekado 3y ago
> Guix, being a GNU project, obsessing over nON-fReE As a long time contributor to Guix I find that the "obsessing" is regularly done by others when talking about GNU. There's enough useful free software out there that needs packaging, and that's what I do. I don't need the extra headache of special snowflake licenses or custom restrictions. For nonfree software that doesn't have a popular alternative I contribute to guix-science-nonfree. It's barely an inconvenience for users to expressly add another channel to their Guix installation.
- accelbred 3y ago
  When I used Guix, I needed nonfree for Firefox and the upstream Linux kernel. I also prefer to only use free software, and also like them not including proprietary software. Needing a channel was a huge inconvenience as you would often pull your channels and stuff would break, as guix was updated but non-guix wasn't. Managing channel manifests was a pain. Firefox would often be months out of date as well. Moved to NixOS, didn't enable allowUnfree, and had an actually up to date and simple to maintain system. Flakes solves the channels problems too. I had put a lot of effort into making Guix work, but it just had too many usabiltity issues, and the policy on firefox was a major one.
  - davexunit 3y ago
    Counter anecodate: I use guix + the nonguix channel for firefox, linux, etc. and it has been smooth sailing for quite some time.

grumbel 3y ago

Opposite for me. Nix syntax is much more pleasant to use and while Nix error messages are by no means perfect, still more fun than digging through multiple layers of Scheme. Does Guix have anything similar to Nix flakes yet?

civodul 3y ago
I believe the use of Guix channels shown in the article is comparable to Flakes.
- grumbel 3y ago
  From what I understand, channels can be used to extend Guix, but don't quite work like Flakes, more like the old Nix channels. The thing that makes Flakes special is that they allow you to treat Git repositories like software packages. No more need for a distribution to package the software, you can just drop a 'flake.nix' file into the Git repository and that makes it behave like a package that users can install and other Flakes can depend on. I am really fond of the ability to just run software straight from Git, e.g.: nix run github:ggerganov/llama.cpp Makes it really easy to switch versions, fork, patch or otherwise customize things.
  - rekado 3y ago
    The blog post in this submission makes the same point: a git repo can be a channel, you just need to add a file for it.

rowanG077 3y ago

I personally prefer Nix greatly it's just JSON with functions basically. I just find Guile expressions totally unreadable with the brackets everywhere.

gglitch 3y ago
Genuine question, not trying to create or sustain a debate: are there more brackets in scheme than in json? I don't use json much, but the example I find in the "Syntax" section of the Wikipedia article on json [0], looks almost identical to how I'd structure the same data in Scheme, though with more quotation marks [1]. Is this just a bad example? [0] - https://en.wikipedia.org/wiki/JSON#Syntax https://en.wikipedia.org/wiki/JSON#Syntax [1] - Edit: more quotation marks, commas, and colons
- grumbel 3y ago
  The difference is that name/value pairs have a dedicated syntax in JSON and Nix, in Scheme everything is (), doesn't matter if it's a function call, list, assignment, macro or whatever. Makes it very hard to understand what is going on at first glance. Worse yet, the normal Scheme syntax is so ugly that people constantly write macros to hide it. Take this package definition in Guix: (package ... (build-system gnu-build-system) (arguments '(#:configure-flags '("--enable-silent-rules"))) (inputs (list gawk)) Looks like a list with name/value pairs, but it's not, that's just the (package)-macro making that thing behave that way. And it's all quite arbitrary, '#:configure-flags' there is a name/value list too, but constructed completely differently. And the next line with (inputs) constructs a list with (list) instead of with a ' quote, as otherwise the list would contain the symbol 'gawk' instead of the value. Scheme is basically: "Here is the a bunch of Lego, go build yourself a programming language". Other language have syntax that forces at least a minimum of consistency.
- rowanG077 3y ago
  It's about specialization. In JSON brackets have dedicated meaning. In scheme it's () galore. And () doesn't give me any meaning of what's actually there. Not that JSON or the Nix language is perfect, or even good, but this point makes it a lot better then a Lisp for me. Essentially quickly scanning over lisp code doesn't give me any inclination about the structure at all, which I think is very important. I admit I haven't written a ton of lisp so maybe that's the problem.