9 ms·

I started using NixOS over Christmas and I have no trouble whatsoever with the language. It seems pretty lazy for the author to shoot Nix down on the grounds th

I started using NixOS over Christmas and I have no trouble whatsoever with the language. It seems pretty lazy for the author to shoot Nix down on the grounds that DSLs are "always a bad idea." He even has the nerve to mention Mozilla as failing with XUL, while ignoring the success of Rust! Nix is lightweight, pure and maximally lazy. It's a simple DSL that evaluates targets -> derivations (build specs.) Considering it can build an entire OS with so few features, I'm not sure adding a numeric tower and Turing-completeness is really desirable. Also, I'm surprised this article doesn't mention Hydra. Reproducible binary caches and automatic testing are one of the key advantages of these systems -- does Guix use it?

Ericson2314 8y ago
I agree but in fairness Nix is also turing complete. I prefer to think that Nix "out-schemes" scheme.
- paulddraper 8y ago
  Is Guix not?
  - Ericson2314 8y ago
    Guile Scheme and Nix both are.
yjftsjthsd-h 8y ago
> He even has the nerve to mention Mozilla as failing with XUL, while ignoring the success of Rust! Um. Rust is not a DSL; if XUL failed and Rust succeeded, then that's (weak) evidence in favor of "DSLs suck".
jchw 8y ago
I also started using NixOS around Christmas time. I really love NixOS, but I'm at best lukewarm on Nix as a language. Honestly, though, the language is not my current concern. My current concern is actually more about compartmentalization. Being able to run `nix-shell -p` and get a shell with a program installed is super cool. Also, being able to add a package to the system declaratively is super cool. However, one thing I wonder about is workflows. For example, I have a lot of Jetbrains IDEs installed for various languages, but I don't want to pollute my global environment with tools, especially command line tools that pollute the PATH. Let's say I want to use Jetbrains Rider. I can easily start a shell with the dotnet SDK with `nix-shell -p dotnet`, then start Rider under that shell. This is OK, but it feels wrong to me. It feels weird that launching Rider outside of nix-shell won't ever work, yet it's installed globally. And yet, I also kind of want it to be globally installed... Another solution would be to have Nix expressions for every project I work on. This actually seems better and I've adopted it for a couple projects, but it also irks me because it feels half-baked. I don't know where to put these expressions other than next to the project, but I don't think it belongs in version control. Also, I'm very mixed for what belongs in these environments. Should it be personally suited, with my IDE and developer tools? If I do that, I can't share the same code I'd use for my tooling as I would for my Nixpkg (assuming there is a nixpkg) which leads to a divergence I don't like. (Though maybe that can be solved?) I almost want a robust system of working environments that encapsulates this. So, I could think about my Nix workflows as separate environments. Declarative or imperative, and ideally with more encapsulation than a typical nix-shell. Maybe instead of orienting my workflow around opening an IDE and opening a project, I can orient it around opening a project environment and then opening an IDE inside of it. At this point I'm just rambling. I still prefer NixOS for practical reasons, since it makes my complex IOMMU setup a cinch and keeps all of the configuration for it surfaced and documented. But dang, the potential here to shift workflow paradigms is enormous, it feels.
- fao_ 8y ago
  > I don't know where to put these expressions other than next to the project, but I don't think it belongs in version control. What about using .gitIgnore or using a git submodule for them? Ideally you could have one central repo for nix workflows, and then just have git submodule point to the repo's subfolder, so when you do submodule init, it pulls down that specific folder. Otherwise, you could use .gitignore and a symlink to that as you might do with your dotfiles if you manage those through version control.
  - jchw 8y ago
    Dotfiles are another story. I would prefer my dotfiles to be in source control, but they're not yet, as I haven't gotten to checking out the Nix community's tooling for that, and I prefer to not actually version my whole home folder (at least on machines where my actual work is done in the home folder.) I think so far my preference might actually be to just have a separate folder, separately versioned, containing my nix expressions for doing work, centrally. But then I kinda want a system for launching into them so I'm not constantly calling nix-shell manually, and that's where I wonder if I actually just want some more tooling for this here.
    - sterlind 8y ago
      I use `git --separate-git-dir=~/.dotfiles --work-tree=~/` and have a .gitignore set to whitelist only things I want to track. This keeps git from colliding with things I have checked out below. I also have configuration.nix import an expression I checked into my $HOME, so I can share common config between all my machines. For shells, I have a custom `env-python [-p <packageNames>] [-f <extraPaths>]` which brings a fully-configured VS Code (with per-environment config), debuggers and neovim with all the trimmings. Everything inherits in layers so I can add different kinds of environments quite easily. If you'd like, I can share my dotfiles with you. It's pretty custom but the beauty of Nix is you can clone and run!
    - asymmetric 8y ago
      > I would prefer my dotfiles to be in source control, but they're not yet, as I haven't gotten to checking out the Nix community's tooling for that Have a look at home manager[0], I use it and have been very happy so far. [0]: https://github.com/rycee/home-manager https://github.com/rycee/home-manager
deleted 8y ago
[deleted]
Ambrevar 8y ago
(Author here) You are right that the tone is unnecessarily harsh towards Nix. I actually admire Nix a lot, it's simply the the article suffers from too little editing and would certainly deserve a rewrite. I'd like to emphasize more on how much Nix and Guix share and that for the better part Guix should be thankful to Nix! With regard to Mozilla, Rust might precisely _not_ be such a mistake, but you are right, I should praise Mozilla for moving on then (although I know nothing about Rust, so I can only guess here). > I'm not sure adding a numeric tower and Turing-completeness is really desirable. That's what I meant: Turing-completeness comes for free, it does not harm the project and you'll need it sooner or later. Even if the devs don't need Turing-completeness, not adding it to a project is effectively limitating what the user can do with a program. I fell for it myself and at the time, I had the feeling that "a Turing-complete language might be too much for the project." Today, I believe that this thought is mostly an ungrounded gut-feeling. > Hydra Thanks for pointing it out, you are right I should have mentioned it when I wrote about the continuous integration. Will do. Guix itself uses Hydra on the old server and Cuirass (a Scheme-based CI system :p) for the new one.
- juskrey 8y ago
  Can I somehow have NixOS package universe with Guix language?
  - rekado 8y ago
    You cannot use Nix package definitions with Guix. You can, however, easily extend or modify Guix packages. New package definitions can inherit from existing ones and override fields that you may want to change. There is also an API for rewriting dependencies recursively: https://www.gnu.org/software/guix/manual/en/html_node/Defining-Packages.html#index-dependency-tree-rewriting https://www.gnu.org/software/guix/manual/en/html_node/Defini... You can also use Nix as a package manager on top of a Guix system (and vice versa).
  - spindle 8y ago
    Most Nix packages, yes, but the NixOS packages specifically (the ones that build Linux), probably not. NixOS and Guix have slightly different philosophies, e.g. about nonfree software (Guix is generally opposed to including it, although I'm not an expert on the details, while NixOS disallows it by default but only by default), and this affects e.g. device driver packages.
m45t3r 8y ago
I think that Nix expression language is Turing complete. At least by the number of constructs, it seems so [1]. And while I think Nix language is kind of strange, there is at least one reason I prefer it instead of a Lisp (this being a person that uses Clojure everyday at work): no parenthesis. It is not that I think Lisp is a bad language because of the parenthesis: I love the consistency and simplicity of the language. However, Lisp is one of the few languages that I don't feel productive at all without a proper editor setup (rainbow parenthesis, slurp, barf, etc.) and I think this is bad for configuration files since sometimes you simply don't have the proper setup. I can easily edit /etc/nixos/configuration.nix in NixOS using only vi to bootstrap my system. I don't think it would be as easy to do the same using GuixSD. [1]: https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c55 https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c5...
- roptat 8y ago
  What if there was a way to replace parenthesis with syntax? For instance, if you could declare your operating system as: operating-system: ... packages: - vim - %base-packages instead of: (operating-system ... (packages (cons* vim %base-packages))) would that help you? No more parenthesis, the complexity of cons* is hidden behind the "-" and it's pretty trivial to convert between one syntax and the other. If it was possible, how would that affect your opinion on guix? What if the installer came with a pre-configured vim for scheme? btw, I'm also a guix and a vim user, and I don't use anything special for parenthesis. I just close them manually like a grown-up (which is a very usefull skill to have when you want to impress an emacs user :p).
  - civodul 8y ago
    Wisp provides a Python-like syntax for Scheme that gives you something very close to the above: http://draketo.de/english/wisp http://draketo.de/english/wisp . (Though me and my editor don't view parentheses as an obstacle, quite the opposite...)
  - m45t3r 8y ago
    Yeah, this seems way more clean.
sametmax 8y ago
XUL is a DSL, rust is not. And to be fair, so many bad DSL has been done in the past, espacially behind corporate walls, that I understand the avortion for them. And anyone who had to work on a Lisp or Ruby code created by a DSL inspired hacker know the pain. DSL have many problems, but the most obvious one is that you get a language without the testing, documentation, tooling and community of a battle tested general one. And because by nature it targets a niche, the miracle needed for it to get real traction requires even bigger divine interventions. Even if nix was amazing (I couldn't tell, I haven't tried it), and the resulting product, not only fantastic, but worth people switching to it (which is not the same and harder to achieve, or even to recognize with honesty), the scale it would need to become practical may not even fit in the niche it targets.
- jcelerier 8y ago
  XUL and Rust are also absolutely not used in the same place. AFAIK there's no Rust code in the mozilla codebase which actually layout widgets in random UI forms.
pxc 8y ago
Guix does use Hydra, yes: https://hydra.gnu.org/ https://hydra.gnu.org/
- rekado 8y ago
  It's true but this is no longer the default substitute server. For the default we use a custom Guix Continuous Integration tool.
  - pxc 8y ago
    That's awesome! Congrats to the Guix community. :-D I hope that as Guix and Nix drift further apart, both projects can continue to learn from one another. :-)

Ericson2314 8y ago

I agree but in fairness Nix is also turing complete. I prefer to think that Nix "out-schemes" scheme.

paulddraper 8y ago
Is Guix not?
- Ericson2314 8y ago
  Guile Scheme and Nix both are.

yjftsjthsd-h 8y ago

> He even has the nerve to mention Mozilla as failing with XUL, while ignoring the success of Rust! Um. Rust is not a DSL; if XUL failed and Rust succeeded, then that's (weak) evidence in favor of "DSLs suck".

jchw 8y ago

I also started using NixOS around Christmas time. I really love NixOS, but I'm at best lukewarm on Nix as a language. Honestly, though, the language is not my current concern. My current concern is actually more about compartmentalization. Being able to run `nix-shell -p` and get a shell with a program installed is super cool. Also, being able to add a package to the system declaratively is super cool. However, one thing I wonder about is workflows. For example, I have a lot of Jetbrains IDEs installed for various languages, but I don't want to pollute my global environment with tools, especially command line tools that pollute the PATH. Let's say I want to use Jetbrains Rider. I can easily start a shell with the dotnet SDK with `nix-shell -p dotnet`, then start Rider under that shell. This is OK, but it feels wrong to me. It feels weird that launching Rider outside of nix-shell won't ever work, yet it's installed globally. And yet, I also kind of want it to be globally installed... Another solution would be to have Nix expressions for every project I work on. This actually seems better and I've adopted it for a couple projects, but it also irks me because it feels half-baked. I don't know where to put these expressions other than next to the project, but I don't think it belongs in version control. Also, I'm very mixed for what belongs in these environments. Should it be personally suited, with my IDE and developer tools? If I do that, I can't share the same code I'd use for my tooling as I would for my Nixpkg (assuming there is a nixpkg) which leads to a divergence I don't like. (Though maybe that can be solved?) I almost want a robust system of working environments that encapsulates this. So, I could think about my Nix workflows as separate environments. Declarative or imperative, and ideally with more encapsulation than a typical nix-shell. Maybe instead of orienting my workflow around opening an IDE and opening a project, I can orient it around opening a project environment and then opening an IDE inside of it. At this point I'm just rambling. I still prefer NixOS for practical reasons, since it makes my complex IOMMU setup a cinch and keeps all of the configuration for it surfaced and documented. But dang, the potential here to shift workflow paradigms is enormous, it feels.

fao_ 8y ago
> I don't know where to put these expressions other than next to the project, but I don't think it belongs in version control. What about using .gitIgnore or using a git submodule for them? Ideally you could have one central repo for nix workflows, and then just have git submodule point to the repo's subfolder, so when you do submodule init, it pulls down that specific folder. Otherwise, you could use .gitignore and a symlink to that as you might do with your dotfiles if you manage those through version control.
- jchw 8y ago
  Dotfiles are another story. I would prefer my dotfiles to be in source control, but they're not yet, as I haven't gotten to checking out the Nix community's tooling for that, and I prefer to not actually version my whole home folder (at least on machines where my actual work is done in the home folder.) I think so far my preference might actually be to just have a separate folder, separately versioned, containing my nix expressions for doing work, centrally. But then I kinda want a system for launching into them so I'm not constantly calling nix-shell manually, and that's where I wonder if I actually just want some more tooling for this here.
  - sterlind 8y ago
    I use `git --separate-git-dir=~/.dotfiles --work-tree=~/` and have a .gitignore set to whitelist only things I want to track. This keeps git from colliding with things I have checked out below. I also have configuration.nix import an expression I checked into my $HOME, so I can share common config between all my machines. For shells, I have a custom `env-python [-p <packageNames>] [-f <extraPaths>]` which brings a fully-configured VS Code (with per-environment config), debuggers and neovim with all the trimmings. Everything inherits in layers so I can add different kinds of environments quite easily. If you'd like, I can share my dotfiles with you. It's pretty custom but the beauty of Nix is you can clone and run!
  - asymmetric 8y ago
    > I would prefer my dotfiles to be in source control, but they're not yet, as I haven't gotten to checking out the Nix community's tooling for that Have a look at home manager[0], I use it and have been very happy so far. [0]: https://github.com/rycee/home-manager https://github.com/rycee/home-manager

deleted 8y ago

[deleted]

Ambrevar 8y ago

(Author here) You are right that the tone is unnecessarily harsh towards Nix. I actually admire Nix a lot, it's simply the the article suffers from too little editing and would certainly deserve a rewrite. I'd like to emphasize more on how much Nix and Guix share and that for the better part Guix should be thankful to Nix! With regard to Mozilla, Rust might precisely _not_ be such a mistake, but you are right, I should praise Mozilla for moving on then (although I know nothing about Rust, so I can only guess here). > I'm not sure adding a numeric tower and Turing-completeness is really desirable. That's what I meant: Turing-completeness comes for free, it does not harm the project and you'll need it sooner or later. Even if the devs don't need Turing-completeness, not adding it to a project is effectively limitating what the user can do with a program. I fell for it myself and at the time, I had the feeling that "a Turing-complete language might be too much for the project." Today, I believe that this thought is mostly an ungrounded gut-feeling. > Hydra Thanks for pointing it out, you are right I should have mentioned it when I wrote about the continuous integration. Will do. Guix itself uses Hydra on the old server and Cuirass (a Scheme-based CI system :p) for the new one.

juskrey 8y ago
Can I somehow have NixOS package universe with Guix language?
- rekado 8y ago
  You cannot use Nix package definitions with Guix. You can, however, easily extend or modify Guix packages. New package definitions can inherit from existing ones and override fields that you may want to change. There is also an API for rewriting dependencies recursively: https://www.gnu.org/software/guix/manual/en/html_node/Defining-Packages.html#index-dependency-tree-rewriting https://www.gnu.org/software/guix/manual/en/html_node/Defini... You can also use Nix as a package manager on top of a Guix system (and vice versa).
- spindle 8y ago
  Most Nix packages, yes, but the NixOS packages specifically (the ones that build Linux), probably not. NixOS and Guix have slightly different philosophies, e.g. about nonfree software (Guix is generally opposed to including it, although I'm not an expert on the details, while NixOS disallows it by default but only by default), and this affects e.g. device driver packages.

m45t3r 8y ago

I think that Nix expression language is Turing complete. At least by the number of constructs, it seems so [1]. And while I think Nix language is kind of strange, there is at least one reason I prefer it instead of a Lisp (this being a person that uses Clojure everyday at work): no parenthesis. It is not that I think Lisp is a bad language because of the parenthesis: I love the consistency and simplicity of the language. However, Lisp is one of the few languages that I don't feel productive at all without a proper editor setup (rainbow parenthesis, slurp, barf, etc.) and I think this is bad for configuration files since sometimes you simply don't have the proper setup. I can easily edit /etc/nixos/configuration.nix in NixOS using only vi to bootstrap my system. I don't think it would be as easy to do the same using GuixSD. [1]: https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c55 https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c5...

roptat 8y ago
What if there was a way to replace parenthesis with syntax? For instance, if you could declare your operating system as: operating-system: ... packages: - vim - %base-packages instead of: (operating-system ... (packages (cons* vim %base-packages))) would that help you? No more parenthesis, the complexity of cons* is hidden behind the "-" and it's pretty trivial to convert between one syntax and the other. If it was possible, how would that affect your opinion on guix? What if the installer came with a pre-configured vim for scheme? btw, I'm also a guix and a vim user, and I don't use anything special for parenthesis. I just close them manually like a grown-up (which is a very usefull skill to have when you want to impress an emacs user :p).
- civodul 8y ago
  Wisp provides a Python-like syntax for Scheme that gives you something very close to the above: http://draketo.de/english/wisp http://draketo.de/english/wisp . (Though me and my editor don't view parentheses as an obstacle, quite the opposite...)
- m45t3r 8y ago
  Yeah, this seems way more clean.

sametmax 8y ago

XUL is a DSL, rust is not. And to be fair, so many bad DSL has been done in the past, espacially behind corporate walls, that I understand the avortion for them. And anyone who had to work on a Lisp or Ruby code created by a DSL inspired hacker know the pain. DSL have many problems, but the most obvious one is that you get a language without the testing, documentation, tooling and community of a battle tested general one. And because by nature it targets a niche, the miracle needed for it to get real traction requires even bigger divine interventions. Even if nix was amazing (I couldn't tell, I haven't tried it), and the resulting product, not only fantastic, but worth people switching to it (which is not the same and harder to achieve, or even to recognize with honesty), the scale it would need to become practical may not even fit in the niche it targets.

jcelerier 8y ago
XUL and Rust are also absolutely not used in the same place. AFAIK there's no Rust code in the mozilla codebase which actually layout widgets in random UI forms.

pxc 8y ago

Guix does use Hydra, yes: https://hydra.gnu.org/ https://hydra.gnu.org/

rekado 8y ago
It's true but this is no longer the default substitute server. For the default we use a custom Guix Continuous Integration tool.
- pxc 8y ago
  That's awesome! Congrats to the Guix community. :-D I hope that as Guix and Nix drift further apart, both projects can continue to learn from one another. :-)