Nix the language has issues for sure (error messages for starters), but "complexity" isn't really one of them IMO. It's quite a small and simple language.
The complexity comes in with the ecosystem and nix-the-build-system, each of which has a dozen different ways to do any given thing, all of which are in active use simultaneously. Some are pretty baffling, like nixpkgs' dual role as both the main package repository and the (almost entirely undocumented) de facto standard library
Exactly this. One of the first things I tell people struggling with nix is that nix is simple and almost all of the complexity lives in nixpkgs. Knowing where to look for help (is this a nix, flakes, NixOS, or nixpkgs thing?) is one of the hardest problems for beginners.
Nixpkgs specifically needs to be entirely rethought. It has become too large and complex to manage both technically and politically with the number of contributors. Separating out the lib, stdenv/tooling, and package definitions would be a good start.
Configuration is a hard problem as evidenced by all continuous reinvention of configuration formats (YAML TOML XML etc). They're all "simplified" and that's why they fail at more advanced use cases. Once you get over a few syntax quirks and the tendency of advanced users to use a bunch of syntax shortcuts, which are confusing to new users, Nix is actually a very terse but conceptually quite simple functional language which has exactly the right amount of complexity to map to its problem space.
IMO the nix language is excellent as templating language, I'd happily use it instead of jinja2 for generating html at a daily job, maybe this will be possible at some point.
The language is alright, the documentation and rate at which things change is the issue.
You wanted to do something and found a page about how to do it? Cool, good chance it won't work anymore cause it changed. If you do get an error from nixos-rebuild because of your nix files, the error report will probably not be useful either.
Guix is an alternative implementation - based on the same general design principles as Nix. It uses Guile scheme as the language, which is at least a more conventional programming language.
Linux distros work well without systemd. In fact, as someone who at one point worked very heavily with it, systemd being absent from a system almost guarantees that it will work better.
Gentoo has openrc, which is a billion times less insane.
Gentoo with openrc has less problems with the init system than Arch has, at least in my experience.
That aside, systemd is a genuinely terrible software project and a genuinely terrible init system.
Just FYI, before my experience of 5 days a week dealing with systemd, I thought people who disliked it were just exaggerating or wanting to be "different". I assumed most hate it was getting was undeserved. My professional experience made it absolutely clear to me that every piece of hate it is getting is well deserved. It is bad software all around, terrible design decisions, completely unpredictable, hard to debug and all around very poorly integrated into the rest of the system.
I'm a bit disappointed that nobody really answered your question. I admit that maybe asking for Nix to be simpler is a bit loaded, because I think people are right in that Nix is "simple", but it's definitely not simple to use in practice.
Several people have worked on offshoots of Nix and the Nix language that try to address this in different ways. For example, there is Nickel: https://github.com/tweag/nickel
I think the Nix language is OK for what it is: lazy evaluation and functional purity is a good fit for what Nix aims to do. That said... I definitely feel like functionally-pure programming languages have trouble when it comes to trying to write maintainable code. I'm sure that statement would anger some, but it is my personal belief trying to use functional programming languages as a life long imperative programmer: the advantages of functional purity are pretty obvious, but writing code that you can't make sense of later is so much easier for me in functional languages. They're so powerful and elegant that writing nearly indecipherable things feels very tempting at times.
So, I'd be interested in seeing someone attempt a Nix-like ecosystem built around something else. If Bazel can do "hermetic-ish" with Starlark, I reckon you could pull off something like Nix with it, too.
The language is really simple, actually. People who complain about Nix language being hard actually complains about things implemented in Nix being hard.
Nix is essentially jsonnet, which you'd argue is simple... Because your first interaction with it isn't implementing an operating system.
I think the main problem with writing nix configurations is the lack of a good LSP. If I hand autocomplete for options, and some kind of global search (e.g. everything related to `postgres`), it would be much easier to use it.
The Nix@NGI team has one clear mission: to make open source software easier to run—now and in the future.
Through the NixOS Foundation’s collaboration with NGI Zero, we’re tackling over 1,200 NLnet-funded software projects, packaging them for Nix and enhancing their discoverability. Our work focuses on building development environments, libraries, services, and more, while also improving tools and processes for the entire Nix community.
Some people can't seem to see why Nix and Guix are in an entirely different class from traditional package managers, and I don't really want to get into that fight, anymore than I want to get into a fight over whether Rust is better than C++. But for what it's worth, installing and using Nix inside of Arch Linux is not particularly dangerous at all. Nix itself is in the Arch Linux extras repo and can be installed directly through pacman, and it mostly writes to /nix/store so it is unlikely to deal serious damage your Arch install as far as I am aware, or have experienced. The fact that Nix can be used outside of NixOS is relatively important, in fact, since a large amount of Nix users are using it on macOS, and in the future, I would love to see first-class support for BSDs and Windows, platforms that can definitely be supported and have been to some degree already.
I do think that neither Nix nor Guix will fully replace the ecosystem of package managers on Linux, for a variety of reasons, but I think Nix is going to be one of those tools alongside Flatpak and Brew that users use alongside native package management on their platforms. Nix and Guix have some very unique advantages to go along with their disadvantages.
> Some people can't seem to see why Nix and Guix are in an entirely different class from traditional package managers
+1. From talking to people with those views, it's not that they can't see it, it's that they haven't looked and just figured Nix/Guix is different in the way that apt/rpm/APK are different from each other.
> I would love to see first-class support for BSDs
This looks like a technical decision on where to focus investment.
Using words like "bias" and "descrimination" imply there is some wrongdoing.
From a quick read (maybe I'm missing something) this seems to me to be coming from "You didn't fund the project I care about" rather than any wrongdoing.
Bravo to the EU, NLNet and the NixOS contributors making this possible!
reply