Nix Language Primer
binaryphile.com
binaryphile.com
Guix's use of Guile is fundamentally equivalent to the Nix package manager's use of the Nix language, but the approach Guix takes to organizing packages is very different. IMO, the Nix language approach is cleaner and more elegant when it comes to describing packages, but it's not clear whether that's worth the cost of using a domain-specific language. So, it still remains to be seen what's the best approach.
In Nix the idea of "functional package management" is more visible as there are no packages but functions with arguments that would result in a package once evaluated.
Guix shows that this isn't the only way to do it, but it is a good way.
Lazy evaluation does not have to be a language feature. In the case of Guix's `<package>` record, only some of the fields are delayed or thunked.
I haven't used Guix to be able to compare but it saved my life many times. I suspect the advantage for Guix is that it forces things to be better structured.
Nix is an extremely simple language with quite familiar syntax, a kind of JSON with functions and string interpolation.
Note also that Guix uses Scheme a lot more deeply than Nix uses the Nix language, in the sense that Nix uses e.g. shell scripts where Guix uses Scheme statements. Actual “coding” in the Nix language is relatively rare.
We don't use R7RS in Guix. You need to know about the Scheme syntax, obviously (including keyword arguments), and a couple of common procedures like `string-append`, but aside from that you don't really need to know much about Scheme at all.
What comes in handy is the Guix DSL, which provides a convenient way to specify packages and download origins. Guix also has a bunch of utility procedures that are useful extensions to their Scheme counterparts, such as `mkdir-p` (which does what you think it does) or the `substitute*` form to substitute expressions in a file or list of files.
One important difference between Nix and Guix is that Guix does not glue shell snippets together, but eventually compiles to Guile builder scripts, so it's Scheme all the way down.
I skimmed the paper on "Code Staging in Guix" and I think this should be very doable, but I haven't yet tried Guix for real.
This ability seems like it would have huge implications for system development... I've dabbled with such experiments using Nix, but the lack of hygienic code staging makes it a bit icky.
We don't use systemd but the Shepherd, which is written in Guile Scheme, so system services are indeed written in Scheme and can use Guile libraries. It is a common pattern to define services as the result of procedures taking variables as arguments.
System services in Guix don't have to be limited to Shepherd services. The system service framework in Guix is very flexible and can be used for almost any system setup task, even for mere "activation services" that create directories or files. Services can extend other services:
http://www.gnu.org/software/guix/manual/en/html_node/Service...
I really like nix the package manager and like NixOS the distribution, but learning nix the language was an awful lot of work, and I'm not convinced that it couldn't have been accomplished with a language that is more familiar (Guix demonstrates that baked-in lazy evaluation is not necessary). Even tiny things like "sets" as a name for an associative data type make it just that much harder to learn.
Thank you for the compliment btw.
Ideal would be some DSL that isn't even Turing complete, but that's not practical at the moment. Maybe we'll get there some day.
Makefiles are Turing complete: https://nullprogram.com/blog/2016/04/30/
Here's a good description of why I should care: https://yakking.branchable.com/posts/what-and-why-nix/
* Nix 2.0 includes the repl. Just run `nix repl`
* The URL literal returns a string
* It would be good to explain how the `<...>` notation resolves paths from the NIX_PATH. For example `<nixpkgs>` looks for the `nixpkgs` key in `NIX_PATH=nixpkgs=/path/to/channel`
Other pain points:
- the NixOS learning curve is steep. There are two many tools with too many obscure options with sometimes overlapping features.
- small group of maintainers with no real documented security process...just an assurance that they path as quickly as possible
- many packages are old if they're not mainstream
I would love to see the concept of Nix reimplemented in a non-niche language without the fsf zealotry... I'd switch my company to something like this in a heartbeat. I think there's a real business opportunity for someone willing to take that on.
- Versioning
- Getting the package (the actual URL, deciding if you want the package, determining which variant -- sometimes two packages solve the same dependency, etc.)
Source on gdb disabling it? Just writing `gr` in gdb enters the guile repl.
>(gdb) gr Guile scripting is not supported in this copy of GDB.
Strictly speaking "Nix" may refer to two things, and I'm not sure which thing either of you are referring to, nor if you two are referring to the same thing.
Personally I found the nix package-manager a bit odd, but to me that was not a deal-breaker for trying out NixOS. The bigeset problem for me was lacking packages... I was however willing to help the community out by trying to package the things I needed which wasn't already provided for.
But then I had to use the Nix language. And that was a great displeasure, and I ended giving up NixOS all together because of this one pain point.
And to address your comment: I think I've seen similar comments on HN at regular intervals. It's definitely not a one-off comment.
If they had used another more standard language (like LISP!) I would probably still be on NixOS as my main OS.
In the long run, I really hope Guix manages to get something good going. My biggest concern for Guix is that they will restrict the available packages by being overly zealous about package-licensing (like everything the FSF does).
Could you articulate why? I have only been using Nix for ~3 months, but so far I do not really have qualms with the Nix language. Maybe it is because I have written a fair bit of Haskell before.
(Of course, I understand the argument that it would have been more comfortable if an existing language like Scheme was used.)
My biggest concern for Guix is that they will restrict the available packages by being overly zealous a bout package-licensing (like everything the FSF does).
Same here. When I got interested in NixOS/GuixSD I seriously considered using GuixSD, because Scheme is more familiar. But there are just some proprietary packages that I need for work (Skype) and at home. I didn't really feel like having to rely on third-party repositories, etc.
I mean... It's not a "real" language in the sense that there exists any tooling, debuggers, unit-test suites or anything.
You write your recipes and try to see if they work. And when they don't you have no idea why.
With a real programming language (like Scheme) I could evaluate something working, compare it to my non-working stuff and probably figure out where it all went wrong. Chances are I could probably expand the macros and debug my way to a solution right within Emacs without ever launching a single external tool.
There's just this huge gap between what you get and what you expect. And with Nix being a one-tricky pony, there's almost zero incentives for the community at large to try bridge that gap.
Guix co-maintainer here. The Guix project is not run by the FSF; it is part of the GNU project, because we subscribe to the idea of giving users the tools to take control of their computing.
Packages available through the official Guix channel must be compliant with the Free System Distribution Guidelines:
https://www.gnu.org/distros/free-system-distribution-guidelines.html
At the institute where I work we're using channels to provide packages that are not available in Guix proper. It's very simple.
For myself (and I suspect many people) when installing GuixSD, before I even have the system running, I'm going to need to figure out how to package the Linux kernel with firmware for my wifi. Otherwise my ~$3k laptop is basically a brick. That is a big ask right up front. Glancing at the mailing list it seems like discussing non-free software is discouraged. Even if there is some well maintained Linux package on Github it would be difficult to find and evaluate before having any experience with Guix.
It is your project and you can obviously have whatever rules you want. It just seems that Guix and Nix made some odd choices that are going to keep both projects in a very small niche.
1. You can uninstall a thing and it will no longer affect your computer.
2. Your environment will work the same way on your colleague's computer.
3. Your environment will work the same way years down the line.
4. Your environment will probably work the same way years down the line, even after you've applied security updates. If it doesn't, it will probably be clear what's broken/different.
5. You can install many different environments on the same machine, and they will probably all work. On the rare occasions where they don't, it will be because they interact with system services or limited system resources, and it will be clearly defined how that happens.
6. All this is true across most programming languages, system services, and all sorts of tools.
7. You can combine this with direnv (or direnv-mode for Emacs) to make it so that you can just cd into a directory and magically get all the dependencies.
8. You can put the recipe for your environment in Git.
Other than Nix and Guix, I don't know of any tool where these things are true. Docker and Virtual Machines get sort of half way, but tend to rot over time.
But yes, it's difficult to learn and in many cases the usability is poor.
Final bonus point:
9. Nix is so good that it can even make Autotools work correctly.
Nix is probably good for many things, but it's not simple and to me it's trying to do too many things.
As soon as any assumption changes, like for example, adding a third-party application repository, then you need to concern yourself with all of the issues mentioned above, or you'll end up wasting your days on manually building and installing packages locally.
The point of Nix is to do this once only. If you build and it runs, it should do the same for everyone, regardless of what other repositories they use. Package management becomes completely modular and does not depend on some centralized state like a central software repository, or the state of your machine at time of install.
Nix isn't trying to do too many things. It's actually much, much simpler than using a bunch of semi-compatible tools which all attempt to do similar things in ad-hoc ways. Nix is just a dependency management system where dependencies are specified by their content hash. Your machine contains a content-addressable store of objects which can be precisely referenced by any other object. It takes the guesswork out of dependency management. Other dependency managers effectively run a search engine to try and find an appropriate dependency from some search terms.