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