Hacker News Reader

Comment by sterlind | Hacker News Reader

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?

View on HN

(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.

Can I somehow have NixOS package universe with Guix language?

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.

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/Defini...

You can also use Nix as a package manager on top of a Guix system (and vice versa).

I know that Nix users respect Guix (well, the ones who talk on IRC, at the very least), and I'm sure it's mutual ... and I think it's very helpful to make this mutual respect public!

Use Nix, respect Guix, can confirm

The only reason I'm not using/learnign Guix (or contributing meaningfully to Nixpkgs these days, for that matter) is time

And I use Guix, and respect Nix :)

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.

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.

> 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".

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.

> 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.

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.

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!

> 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

> 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.

What do you mean it won't work? I think rider will launch without dotnet, If not then rider dependencies should be fixed to include dotnet. Otherwise, it's the same case for any other distro.

> but I don't think it belongs in version control.

Why not? In fact you should put them in vc since anyone with nix can easily build the program exactly same as on your machine.

> Should it be personally suited, with my IDE and developer tools?

You can create different nix files: e.g. in ide/default.nix you can inherit your default shell.nix and put extra dependency. You may want to skip checking this in vc though.

For a good organization of nix files look at the reflex-frp haskell project.

Rider launches without dotnet, but is not very useful. It becomes effectively a text editor.

Of course, if you wanted to use rider without dotnet, you could. But it doesn't fit my workflow.

And yes, like I said, this is still better than the situation on other distros, but it feels like it's close to being even better than that.

>Why not? In fact you should put them in vc since anyone with nix can easily build the program exactly same as on your machine.

For starters, because I work on a lot of projects that aren't mine. But also, because it's not really standardized.

Like there's a fairly standard practice for putting a package.json in a repository but not really so for default.nix. And it's also not exactly orthogonal to Nixpkgs; if you wanted your project to be in Nixpkgs, your expression would be (slightly) different. That is probably solved by importing the Nixpkg into default.nix, but I haven't tried yet.

Finally, this doesn't capture everything. If I want an environment where I have VSCode with the Go extension installed, I would prefer that to be isolated from other VSCode instances.

That's why I think I want more than just a Nix expression. The tools to do what I want are all here, but the tool to automate the workflow is not.

> If I want an environment where I have VSCode with the Go extension installed, I would prefer that to be isolated from other VSCode instances.

You can absolutely do this by overriding the derivations. The tool to automate your workflow is there(just create a bunch of nix files and a makefile to call nix-shell/nix-build), but not as convenient as you might like.

Check out `users.users.<name?>.packages` for a declarative way of installing user-specific (non-global) packages.

https://nixos.org/nixos/options.html#users.users+packages

That is cool, but I actually kind of like keeping most things system scoped. What I'd like to do is move everything that is not system scoped into a more granular environment.

> 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...

I use nix-buffer[0], which lets Emacs pick up the environment automatically when I open any file in the project. And as long as you only use setq-local it'll stay scoped to those files, "normal" files still open in the regular user environment. It's even seamless to keep files from multiple such projects open at once.

[0]: https://github.com/shlevy/nix-buffer

> I also started using NixOS around Christmas time.

Hah, me too. :)

> I really love NixOS, but I'm at best lukewarm on Nix as a language.

My biggest issue as of now is that the documentation focuses on which individual files you need to touch, but doesn't really explain the big picture. For example, /etc/nixos/configuration.nix contains a function that takes { config, pkgs, ... }. Where do these come from? Where can I find documentation for them? What is in the ellipsis? More generally, where can I find a high-level overview of how the different components interact with each other during, for instance, nixos-rebuild?

All the quirks are little design patterns that look pretty weird at first, not language features themselves. The resource you're looking for is the Nix Pills series [0]. The LearnXInYMinutes on Nix is also a good overview of the syntax.[1] nix repl is also essential for feeling it out.

To answer your question, { config, pkgs, ... }: declares a function that takes an attribute set containing values for "config" and "pkgs". The ellipsis indicates that it's okay to pass extra attributes.

Nixos-rebuild calls your function by: with (import <nixpkgs> {}); callPackage ./configuration.nix {}

<nixpkgs> is a file containing the set of all symbols (packages are under pkgs, Nix config lives in config, etc.) like a root namespace. callPackage inherits all those symbols and passes them to the function, which is how they got bound.

0. https://nixos.org/nixos/nix-pills/index.html

1. https://learnxinyminutes.com/docs/nix/

EDIT: I guess it's also like Git where it's really confusing until a moment of enlightenment where it all makes sense.

NixOS doesn't actually use callPackage. it uses lib.evalModules. The fact there is a difference between how NixOS is evaluated, vs how Nixpkgs is evaluated is something I actually find quite annoying. Whilst nixpkgs is all about functions and dependency injection, NixOS is all about merging dictionaries.

Here is some context, with corresponding criticsm by the person behind Guix, which might give some interesting insights

https://discourse.nixos.org/t/best-resources-for-learning-ab...

Maybe you'd like `makeWrapper`? It's a little utility which replaces executables with small shell scripts, which set up env vars and PATH components, etc.

I'm not familiar with Jetbrains or dotnet, but you could probably use makeWrapper to make a "jetbrains-with-dotnet" package, something like this:

    with import <nixpkgs> {};
    runCommand "jetbrains-with-dotnet"
      {
        inherit dotnet jetbrains;
        buildInputs = [ makeWrapper ];
      }
      ''
        mkdir "$out/bin"
        makeWrapper "$jetbrains/bin/jetbrains" "$out/bin/jetbrains-with-dotnet" --prefix PATH : "$dotnet/bin"
      ''

This package provides a `jetbrains-with-dotnet` script, which adds the `bin` directory of the `dotnet` package to the start of $PATH then runs the `jetbrains` executable from the `jetbrains` package.

Installing such a package globally will put the `jetbrains-with-dotnet` script in your PATH, but it won't pollute your system with anything from dotnet or jetbrains: those will be downloaded/built and cached in the Nix store, but are only accessible via that script.

Making working per-project definitions in NixOS is what ultimately got me to drop NixOS :(

The specific reason is Ruby + RoR leading to nokogiri... which is something people have been dealing with for several years and there's no solution, and I lost the one file where I managed to get it working good enough to launch rubymine in a way that sees everything necessary.

Similar issues crop in other places, due to how Nix dependencies are handled like unflattened node_modules at times :/

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-a0063a1a4c5...

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).

Wisp provides a Python-like syntax for Scheme that gives you something very close to the above: http://draketo.de/english/wisp . (Though me and my editor don't view parentheses as an obstacle, quite the opposite...)

Yeah, this seems way more clean.

The whole problem with that notation is that it isn't declarative. It's mean to execute. So to read it you have to know Guile functions like cons* . vim and packages% are actually variable bindings; vim undoubtedly stands for some package object defined elsewhere.

A Scheme-based configuration language that is executable Scheme is going to end up using the entire language, and be daunting to some IT person who just wants to reconfigure the distro and isn't a Scheme programmer. (Counterargument: a clean, dedicated configuration template language will likely sprout a way to run arbitrary Scheme code anyway.)

It's tempting to make things like this because they are quick and dirty. For instance, we could make an assembly language which is like this. (mov eax ebx) could be a call to a function called mov, and eax and ebx could be constants in Scheme itself. The function has the side effect of emitting the assembled code into some stream. We don't have to write any code which would walk, validate and translate the syntax of a Lisp-ified assembly language; we just let the programmer write code using the API we have provided and throw it into the path of the evaluator.

And we can have fun like (dotimes 13 (roll %ecx)) to emit 13 copies of an instruction.

So it has some up-sides, and some down-sides.

There you're replacing a configuration language that is executable Scheme, with what seems to be a declarative language, and converting to indentation syntax. That's a two-variable change.

The original S-exp syntax doesn't have to be an executable program in which you use Scheme operators like cons* .

The indentation-based notation, likewise, can retain the property that it's executable Scheme and reveals operations like cons* to the user.

"Too many parentheses" isn't a valid argument IMHO. It comes up so often that I wrote a standard response http://chriswarbo.net/blog/2017-08-29-s_expressions.html

tl;dr s-expressions are (by design) trivial to both parse and generate, and there are already a bunch of tools to convert to/from a other formats (such as indented text). There's no need to create/use a whole different language+toolchain+ecosystem just to avoid parentheses.

This post shows exactly what I mean: editing Lisp with a good editor is nice, however when you're bootstrapping a system sometimes the only tool available is vi (no even vim, just vi).

Try to find a close parenthesis after 8 function calls without syntax highlighting, or without your "hide parenthesis".

Nix syntax is quite simple to read even without any editor support. I did the whole bootstrapping of my current NixOS system only using vim without special support for Nix language and still got it right in my first try.

Vi has % to jump to a matching parenthesis as pretty ancient feature. It's in POSIX:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...

Of course % is a movement that combines with commands like deletion: d%.

The original vi also has a Lisp mode (not described in POSIX) for indentation; that is of course in Vim also.

All the code you see here was written using little more than indentation via Lisp mode and % for paren matching:

http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib

Though I work with syntax coloring and sometimes use Vim features like visual selection.

> Vi has % to jump to a matching parenthesis as pretty ancient feature.

I know. It helps, but it is far from being good enough. Making things like slurp is still a pain without proper editor support, and this is very common to do in Lisp.

> All the code you see here was written using little more than indentation via Lisp mode and % for paren matching:

Yeah, and K&R written Unix with only ed. My point still is valid: Nix is more readable than Lisp without proper editor support.

Also, any half decent Lisp dialect can tell you where an unbalanced parenthesis lies; you shouldn't have any difficulties hunting for this in a large file.

  $ txr unbal.tl 
  unbal.tl:8: syntax error
  unbal.tl:8: unterminated expression
  unbal.tl:8: while parsing form starting at line 5
  $ pr -Tn unbal.tl
      1   (defun foo()
      2   
      3     )
      4   
      5   (defun bar()
      6     (let (x)
      7       )

I don't think this is a great error message. I use Clojure everyday and I still had to look 2 times to find the error.

If it was something like this, this would be much better:

  Unmatched parenthesis from starting at line 5.
  Maybe you wanted to do something like this?
      1   (defun foo()
      2   
      3     )
      4   
      5   (defun bar()
      6     (let (x)
      7       )
               ^

This being a very basic code. In reality you will have multiple function calls inside more complicated functions (like a package definition in Guix), so you will end closing 10+ parenthesis and catching them can be hell.

> This post shows exactly what I mean: editing Lisp with a good editor is nice, however when you're bootstrapping a system sometimes the only tool available is vi (no even vim, just vi).

Then I think you misunderstood. My point is that if you don't like parentheses, then don't use parentheses. Lisp doesn't care. Denote structure in whichever way you prefer, and convert that to/from s-expressions programatically.

Guix runs on Guile Scheme. I-expressions (which use indentation instead of parentheses, which I linked to in the post, https://srfi.schemers.org/srfi-49/srfi-49.html ) contains an implementaion for Guile right there in the spec. Likewise the code repos for Sweet expressions and Wisp (which also allow mixfix, braces, etc. and I also linked to in the post) seem to provide explicit Guile support too, alongside other systems (e.g. Racket) and standalone conversion scripts for compatability with any other s-expression system. Guile also has a built-in implementation of "curly-infix expressions" ( https://www.gnu.org/software/guile/manual/guile.html#SRFI_00... ).

That's 4 ways to use Guix without reading or writing any parentheses; one of which comes built-in. It's also pretty trivial (thanks to the simplicity of s-expressions) to make up your own alternative if you don't like any of these.

I agree but in fairness Nix is also turing complete.

I prefer to think that Nix "out-schemes" scheme.

Is Guix not?

Guile Scheme and Nix both are.

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

It's true but this is no longer the default substitute server. For the default we use a custom Guix Continuous Integration tool.

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. :-)

Reply on news.ycombinator.com