The Nix NGI Team: Advancing Open Source with Nix

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

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.

Nix is actually really simple (basically json with functions) and can be learned in under an hour, see https://nixcloud.io/tour/?id=introduction/nix

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.

There's Lix, although I'm not clear on if it's about changes to the language or if it's entirely focused on improving the tooling.

https://lix.systems/

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 language is possibly the simplest programming language known to man. Try to "simplify" it further and you'll get raw lambda calculus.

In short, no, the language is not the source of difficulty.

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.

This is very cool. Can you disclose how much funding NixOS is getting via NGI Zero?

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.

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.