8 ms·

I read of Nix now and then. Seems its more than a fad. Why should I invest time? What makes it stand out?

colordrops 4y ago
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.
- grawp 4y ago
  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.
  - colordrops 4y ago
    Is Nix used for anything besides configuring a computer? I said "a lot more to it" as well...
    - JamesSwift 4y ago
      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).
      - colordrops 4y ago
        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.
alchemist1e9 4y ago
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.
flexiondotorg 4y ago
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.
- throwaway894345 4y ago
  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.
dandanua 4y ago
I found NixOS to be usable (though it has limits in comparison to other distributions), reliable and reproducible(!). You can add and remove packages without polluting the system. Potentially it can save you time in the future. Moving to another hardware is a breath.
superkuh 4y ago
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 libraries 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.
grawp 4y ago
- 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.
rgoulter 4y ago
> 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.
- fuball63 4y ago
  How does Nix compare to Environment Modules: https://modules.sourceforge.net/ https://modules.sourceforge.net/ Am I correct in understanding they are similar, except Nix has the "pure" package building?
  - rgoulter 4y ago
    I'm not familiar with Environment Modules. I see they're popular in HPC? One difference: On Nix's homepage (https://nixos.org 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 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 https://github.com/freuk/awesome-nix-hpc
unshavedyak 4y ago
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.
- seanw444 4y ago
  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.
  - unshavedyak 4y ago
    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.
    - seanw444 4y ago
      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.
  - tripdout 4y ago
aendruk 4y ago
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.
tylerjl 4y ago
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/ https://devenv.sh/
blueflow 4y ago
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.

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.

grawp 4y ago
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.
- colordrops 4y ago
  Is Nix used for anything besides configuring a computer? I said "a lot more to it" as well...
  - JamesSwift 4y ago
    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).
    - colordrops 4y ago
      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.

alchemist1e9 4y ago

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.

flexiondotorg 4y ago

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.

throwaway894345 4y ago
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.

dandanua 4y ago

I found NixOS to be usable (though it has limits in comparison to other distributions), reliable and reproducible(!). You can add and remove packages without polluting the system. Potentially it can save you time in the future. Moving to another hardware is a breath.

superkuh 4y ago

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

grawp 4y ago

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

rgoulter 4y ago

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

fuball63 4y ago
How does Nix compare to Environment Modules: https://modules.sourceforge.net/ https://modules.sourceforge.net/ Am I correct in understanding they are similar, except Nix has the "pure" package building?
- rgoulter 4y ago
  I'm not familiar with Environment Modules. I see they're popular in HPC? One difference: On Nix's homepage (https://nixos.org 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 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 https://github.com/freuk/awesome-nix-hpc

unshavedyak 4y ago

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.

seanw444 4y ago
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.
- unshavedyak 4y ago
  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.
  - seanw444 4y ago
    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.
- tripdout 4y ago

aendruk 4y ago

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.

tylerjl 4y ago

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/ https://devenv.sh/

blueflow 4y ago

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.