> Why should I invest time?

It's not for everyone.

Specifically, because Nix's 'costs' are upfront (for likely future benefit), nix isn't well suited to just-get-it-done pragmatic attitudes. -- e.g. if you'd prefer to just launch VMs from the web console, over using a tool like Terraform, then Nix isn't going to be for you.

Nix isn't too difficult to use. I'd say it's 95% wonderful, 5% huge pain to deal with. (Writing new nix code can be very hard).

As to why it's worth learning:

> What makes it stand out?

Nix provides very expressive control over packages of software.

e.g. With nix, it's easy to have multiple versions of the same software running on the same system. Whereas, with package managers, if you upgrade, you aren't able to easily also keep the old version around.

Some of the use cases Nix allows are pretty neat:

- You can declare a set of development tools to be made available. So, when you load up the project, you don't have to copy-paste "apt-get install...". This is especially useful for side projects you might not touch all the time.

- There's a "nix run" command, which can act a bit like "docker, without containers": it will download the package, and run it on the host.

- NixOS makes use of Nix so that the system configuration is all declared starting from a single file. Rolling back changes to system configuration is easy, in case you accidentally misconfigure the system. -- This can be used to build container images or VM images.

- Nix can be used to declare what packages you want installed for your user, and declare the configurations for these files. This allows ensuring you have a familiar setup quickly on a new computer.

All sorts of programming involves dealing with packages.

To clarify a bit on the details: nix declares packages in a pure way, using all of its inputs (source code, compiler, library dependencies; which are themselves declared with nix), and builds these in an isolated/non-global directories. Packages are 'installed' by symlinking to where the package is placed.

How does Nix compare to Environment Modules: https://modules.sourceforge.net/ Am I correct in understanding they are similar, except Nix has the "pure" package building?

I'm not familiar with Environment Modules. I see they're popular in HPC?

One difference: On Nix's homepage (https://nixos.org), the first word which stands out is "reproducible". -- If I search the read the docs for "reproducible", the word shows up once. https://modules.readthedocs.io/en/latest/index.html

Not sure if there's anything recent, but links from this may be useful: https://github.com/freuk/awesome-nix-hpc

This is not Nix, but in showing the Environment Modules support for Guix the blog post also shows how functional package management (as implemented in Nix and Guix) differ:

https://hpc.guix.info/blog/2022/05/back-to-the-future-module...

Helpful article and cool feature! Thanks for sharing

Modules imperatively modify the current (shell) environment (PATH and other variables) but you've to install anything required by modulefiles yourself. Nix handles package management and also allows you to declaratively create an environment to which you enter. For example `module load gcc` will bring gcc to your environment but it must already be installed by the administrator. On the other hand on Nix, you can either do something similar with `nix-shell -p gcc` which will give you an environment with gcc that if it isn't available on store will download it, but you can also create a `shell.nix` where you specify anything you need explicitly (have those packages available, download those dependencies not available as packages, make those config files, etc). Overall Modules has only a part of the functionality offered by Nix.

*Although `nix-shell` in newer unified `nix` command has been broken to few subcommands. Can find more info at https://blog.ysndr.de/posts/guides/2021-12-01-nix-shells/ if interested.

> nix isn't well suited to just-get-it-done pragmatic attitudes

Depends on what exactly you're trying to do. I discovered nix years ago when I was trying to install a newer version of Java than was available in the Ubuntu repos, and the "nix-env" method (just using nix as a package manager without the declarative config) was the only thing that just worked with no hassle.

* * *

For me, i use it on my Desktop because i love things being stable for my work environment. I don't want an upgrade over the weekend to cause problems come Monday morning.

I've had my system get "borked" on updates in the past, and Nix lets me revert very very easily. Also upgrading libraries for one App can easily be isolated from breaking other applications and etc.

It's got tons of flaws (to me), but the core idea to me is a foundation for a super stable system. I both love Nix and hate it. It's so good that myself, a large critic of the OS, still uses it.

For me, the "borking" issue is largely resolved by running Btrfs. Just make a snapshot shortly before updating, and then I can revert to it if needed.

My problem is i don't know what gets borked immediately after updating unless it's catastrophic. Ie i've gone a fair bit of time before i realized some specific functionality of some program no longer works due to some unrelated change in an underlying dependency that i was unaware of. Oof.

Granted Btrfs sounds great though, i've not used that. It would certainly help.

Yeah that's true. That's where the "largely" part of my comment does some work.

I just take occasional snapshots before I do things that I'm concerned may be catastrophic. But it definitely won't catch everything. It helps that I run Arch, and I update packages once a day, which only leaves me with under 40 (small) packages usually. So a quick cursory glance at which ones are updating usually tells me what to be cautious of. Display driver update, kernel update, etc.

If I'm not sure what went wrong, but I at least have a working snapshot, then I can get done what I need to get done, and then go back to troubleshooting. Rather than just having a broken system regardless.

I used to employ ZFS for this, but if it took me a while to notice something was broken, or I updated multiple times, it was annoying to figure out which snapshot was the issue, and which changes actually caused the problem. On NixOS, I just have to select a different generation in systemd-boot, and since my configuration is stored in a Git repo, they're all tagged with the data and commit hash they were built at, so it's very quick to a) find a working generation to just use for now, and b) actually find where the issue is and solve it.

- Nix is a purely functional language with lazy evaluation. - One of its types is a derivation which is basically an immutable result of some script / application / other build system ran in sandbox with exactly specified environment. - Calling derive with same inputs generates same derivation. - It's lazy... only when something tries to access derivation's files or other properties its build script is run.

You can use derivations as (/ to represent) - packages - generated configuration files / settings - containers - whole OS images ... e.g. I'm building raspi SD card images using Nix.

Nix is for people who have entirely given up on the idea of system libraries. There is no system. Unless someone else has already done the work every single random bit of .c code, or whatever, you try to compile or run will require you to explicitly set the system libaries available/required to run it in a set of config files. It's like building a custom OS container for every single program you run.

For some people this is good because future shock has made relying on system libaries to run things very troublesome. So troublesome it compares to the above.

Closing in on 20 years of existence doesn't really qualify for fad

I'm just starting a serious learning journey with Nix after flirting with the idea for a few years. Mostly because I find myself endlessly working on tooling to support the projects I work on that Nix already does extremely well.

The feature I am most sold on is the ability to invoke clean complex development environments, that bring themselves to existence automatically as I traverse directories. If you work in code or in DevOps, Nix is totally worth a look.

It may not be a fad, but there's a lot of rose-colored hype that masks a world of tedium. New prospective users should be prepared for a lot of uphill grind with respect to configuring packages or defining their own packages. Every time I try to do seemingly simple tasks in Nix, I end up spending hours on the Nix discord channel trying to work out a solution with seasoned users (who invariably struggle to work out a reasonable solution). Often times I end up having to try to figure out how to package some obscure C dependency deep in the dependency tree with its own bespoke build system and so on. Nixpkgs is also pretty poorly organized (or at least I can almost never find the package I need) and this is pretty critical because something as simple as answering "what type does this function take?" requires a ton of searching around Nixpkgs (largely due to the lack of type annotations or even informal documentation). The CLI tool surface is also not particularly intuitive, and there are different tools for different problems and no consensus about which tools to use (or at least the official docs often disagree with popular opinions in the community). You have to be aware of whether you're just using the Nix package manager or whether you're using NixOS because it will affect the way you write your configuration and often snippets on the Internet implicitly assume one or the other such that you will spend a lot of time trying to fix snippets or find the right snippet for your use case. MacOS is still a second-class citizen in the Nix world and a fair amount of stuff doesn't work properly (although I can't think of specific examples off hand). The Nix expression language seems unnecessarily unfamiliar to mainstream programming languages--I don't object to the functional nature, but I still spend quite a lot of time consciously thinking about syntax even though I've been using Nix on and off for ~7 years now (compared with e.g. typescript which I've barely touched and yet is trivial to read). Normally I don't complain about syntax, but you can do very little in the Nix world without reading and writing a bunch of nixlang and even if the other problems were resolved this alone would make it difficult to sell in most organizations since every developer would have to figure out how to work with it (package management is high-touch).

I'm a big believer in Nix's high-level approach to declarative systems, but the whole UX of Nix is so poor that foregoing declarative systems altogether is quite a lot less painful than using Nix in my experience. I'm rooting for it, but it really feels like Nix needs a product manager or something (no disrespect to the maintainers; these are difficult problems and I'm sure I wouldn't do a very good job). New users should beware.

> MacOS is still a second-class citizen in the Nix world and a fair amount of stuff doesn't work properly

In my experience:

With fewer nix users on macOS, it's more likely you'll run into software which isn't in the binary cache, & so will compile from source. (brew also does this).

With fewer nix users on macOS, it's may take longer for packages broken on macOS to be fixed.

It's a bit more of a hurdle to use .app programs out-of-the-box compared to brew, due to the symlinking.

.app programs which require Xcode to build weren't in the binary caches altogether, last I checked. Stuff with proprietary software in its build toolchain doesn't get built on Hydra.

I just use brew for .apps (and only for .apps) when I'm on macOS.

Yep, I use Brew with a Brewfile to handle most casks. A select few I've manually created derivations for. This seems to be the path of much less resistance.

> With fewer nix users on macOS, it's more likely you'll run into software which isn't in the binary cache, & so will compile from source.

This isn't necessarily true, unless the package happened to fail to build on Hydra, or it just hasn't been built yet. (Every package is built for every platform that has builders in Hydra, it's not a matter of maintenance unless it just doesn't build.)

Does brew do this differently? I thought they also automatically compile every package.

I feel like Nix is worth it for me at this point, but I've definitely been through some of the pain described. This is a tough critique to hear for anyone who loves the project but I agree with the core of it (except the syntax issue).

Worth reading for Nix people and prospective Nix users alike, imo.

Yeah, I don't want to rain on a parade; I think about it as opportunity for people who care about the project to rally around. I know plenty of people care about the user experience, but the current efforts seem kind of superficial and limited. It kind of feels like efforts are geared toward making Nix slightly better for its current user-base: individual, super-technical users who are really excited about package management and functional purity. Sadly, this misses out on Nix as a package manager for larger organizations (packaging their own software as well as configuring their hosts) as well as individual users who want the benefits of declarative systems but who don't want to learn a ton about package management, functional programming, Nix minutia, etc.

IMHO, it seems like there should be a UX working group that starts with broad scenarios and personas and develops a vision of what tooling should look like and works from there, rather than haphazard, incremental improvements on the current state of Nix tooling/workflows/etc. It could be interesting to look at how the Rust project makes big ambitious changes (they seem to do a really good job from my vantage point). Again, this is my view from afar as someone who has never run a big open source project and knows relatively little about package management (though thanks to Nix, much more than I ever wanted to know!).

> MacOS is still a second-class citizen in the Nix world and a fair amount of stuff doesn't work properly

and that will stay this way if Apple continues to make major and breaking changes with every update and changing MacOS more and more away from a BSD system and locking it further down.

If you are building a complex system with a large number of cascading dependencies then nix can literally save your sanity, however you have to get over the initial steep learning curve.

If your work tends to be more isolated and self contained on stable unchanging mainline or mainstream versions of any dependencies you have. Then it’s not worth your time and you won’t appreciate or understand it’s value.

* * *

It's basically checking in your OS to git. It never gets crufty and almost never breaks. There's a lot more to it but those are the core ideas and I'm typing on my phone.

NO. He asked about Nix NOT NixOS... do not conflate them together. Nix an extremely generic tool for much much much more than what you have said.

Is Nix used for anything besides configuring a computer?

I said "a lot more to it" as well...

Yes, its used to guarantee reproducible scripts (so, e.g., you can use `jq` and not require someone have jq installed and not require running through docker) and dev environments as well (which is really great for both version locking as well as polyglot projects).

I use nix shell for development and reference uninstalled packages from scripts as well. I think we both understand what Nix is capable of. I still don't find any issue with my initial comment that Nix at its core is for maintaining a reproducible system from config files in git. My point wasn't to be pedantically perfect but rather to communicate a core use case in laymen's terms for the uninitiated.

NixOS has been my daily driver for just over a year and my impression is that it’s still all a big experiment. A promising one, but far from a polished product so try to avoid that framing.

The Nix community is doing exciting work but in the long run I wouldn’t be surprised to see another project take its place in the mainstream once the ideas have matured. The current space has much of the same chaos as projects like Oh My Zsh or Spacemacs and needs to be treated more like an active hobby.

All that considered, the core paradigm is a breath of fresh air and I can’t imagine going back to a mutable system.

I think the nix community is doing an increasingly-better job at addressing several outstanding issues, and although the OP link resolves one of them - the getting-started experience - the "why" that you highlight here is still a hard one to answer without getting into the technical weeds. I ran an informal Twitter poll a few months ago and this question (the "why" instead of "how") was the most-requested kind of content.

One potential answer to this is, "imagine building and running software with lockfiles for _literally everything_". I'm not just talking about _versions_ of dependencies or shared libraries - which nix does - but also things like:

- Locking the current point in time (nix resets the build sandbox to the unix epoch)

- Locking out network conditions (all build dependencies need to be fetched and therefore expressed as part of the instructions and not left to "at some point during the build")

- Locking out access to any system state (again, builds occur in a sandbox populated only with what you indicate within the build instructions)

That's what's behind the marketing for reproducability and repeatability. If you lift those principles into new and interesting applications, the various other uses for nix fall out of it:

- NixOS takes the principle of those nix builds and applies to it building not just packages, but the system entirely, like the files it places in /etc or the running kernel.

- Projects like devenv[1] or flake devShells in general re-use the portability of a fully-defined nix package to ship hard-to-break executables into share-able devshells so your peers can work with the bit-for-bit same version of Terraform or python (without worrying about what version of /lib/libssl.so they may have)

- Since nix "owns" the _entirety_ of the inputs and outputs to a piece of built software, shaping it into different artifacts becomes trivial. For example, as long as you're able to build a rust project with nix, nix easily lets you kick out a minimal OCI container (without needing to write a `Dockerfile`), or produce a tiny qemu clone of your system (or any system) by feeding your NixOS configuration into a function that produces images instead of configuring your running system.

Hopefully that's helpful, sorry if it isn't - but nix is sort of alien software, and nix people are still learning how to best share its potential with others!

edit: list formatting

[1]: https://devenv.sh/

I recommend to sit back and wait until the hype has subsided. Later, when the starting problems subsided and documentation has improved, it might be worth a try. Provided that ever happens.