3 ms·

I have been in a deep rabbithole with Nix lately. It seems almost too good to be true. Declarative configuration, and with NixOps, declarative provisioning as w

by sali0 6y ago

I have been in a deep rabbithole with Nix lately. It seems almost too good to be true. Declarative configuration, and with NixOps, declarative provisioning as well. Along with the other tools in the ecosystem, there is quite some overlap with some of the popular tools from Hashicorps and others. I am just beginning to learn the intricacies of DevOps, and Nix seems like a one-stop shop. What are the downsides of Nix?

darthrupert 6y ago
The downsides are complexity and dissimilarity to existing things, which lead to not many people knowing how to use it.
aidenn0 6y ago
I've been using it for 5 years at this point and love it. Biggest downside is that it's so different, which confuses e.g. upstream. Second biggest downside is that getting things right in a declarative manner is a bit more upfront work.
throwaway894345 6y ago
The Nix language is a big one, the lack of typing and comments which might help readers navigate Nix code, the arbitrary directory structure of nixpkgs, the very dynamic nature of derivations (if these keys are present on the derivation it will do one thing otherwise it will do very different things), the lack of documented escape hatches for things that you don’t care to make reproducible (in a perfect world, I would make my Python dependencies reproducible but the system package works well enough on my system and I can’t be bothered to write a recipe that builds some autotools-based C project with its own dependencies on obscure C projects scattered across the Internet, each with their own special snowflake build systems and their own dependency trees), etc. Nix is definitely the right direction (it could completely solve the monorepo/multirepo problem and dramatically simplify CI/CD and otherwise significantly improve software development), but it’s not very pragmatic. It badly needs some product leadership.
X6S1x6Okd1st 6y ago
Specific to NixOs, but running software that hasn't already been packaged for nix can be quite hard. The language is not simple and discovery can be quite lacking.
ywei3410 6y ago
When it’s hard to do something in Nix, it’s really hard. Let’s say you download a random binary which isn’t part of the Nix distribution — it is unlikely that you can run the binary; you may need to run ldd or nm to check the headers or construct the LD_LIBRARY_PATH manually. So many random build scripts assume certain things like cp exists in /bin/cp or use absolute paths (looking at you Python) that I tend to find I’m yak-shaving pretty often. The documentation for Nix… is special. I’ve never seen any configuration need to explain the fixed-point [1] in order to do something which should be pretty simple. On the other hand, when it works, it works brilliantly. I have projects where I want to fetch some random URL, or build some randomly generated C file; previously which I would have just said sod-it and checked it into the repository. Being able to share crafted environments ala direnv to colleagues and the continuous-integration is magical. Having per-project environment management which doesn’t require 3-4 tools like virtualenv, nvm, docker, docker-compose is really nice. [1] https://nixos.org/guides/nix-pills/nixpkgs-overriding-packages.html https://nixos.org/guides/nix-pills/nixpkgs-overriding-packag...
GlennS 6y ago
Speaking to NixOps in practicular, I've used quite a bit at previous jobs, and still use it for my personal stuff. It's very good and convenient (if you already know Nix), but it doesn't have a lot of maintainers so it's missing a lot of features compared to Terraform. For a lot of people these features don't matter, but at companies over a certain size they're probably be considered table stakes: * Not really a good story out of the box for teams, because the state file is just an SQLite database on your computer. Terraform has all sorts of helpful options for where to store its state file. There was some work in progress to improve this on NixOps last time I looked. * Doesn't support AWS load balancers. There is support for Azure load balancers though, so maybe this will come in the future? You can setup a load balancer separately and point it at your NixOps deployed instance, but meh. * Doesn't support AWS ECS/Fargate, which is a shame because that would be an excellent combination (building a customized NixOS docker image is very easy and space-efficient). * Doesn't support authenticating with temporarily assumed AWS roles. AWS "best practice" encourages using these. On the other hand, it does have one feature that Terraform doesn't: you can very easily build and deploy your code at the same time as your infrastructure. Whether it's actually a good idea to do so is up for debate, but it's certainly convenient. It's also usually a bit faster than Terraform I find.

by sali0 6y ago

darthrupert 6y ago

The downsides are complexity and dissimilarity to existing things, which lead to not many people knowing how to use it.

aidenn0 6y ago

I've been using it for 5 years at this point and love it. Biggest downside is that it's so different, which confuses e.g. upstream. Second biggest downside is that getting things right in a declarative manner is a bit more upfront work.

throwaway894345 6y ago

The Nix language is a big one, the lack of typing and comments which might help readers navigate Nix code, the arbitrary directory structure of nixpkgs, the very dynamic nature of derivations (if these keys are present on the derivation it will do one thing otherwise it will do very different things), the lack of documented escape hatches for things that you don’t care to make reproducible (in a perfect world, I would make my Python dependencies reproducible but the system package works well enough on my system and I can’t be bothered to write a recipe that builds some autotools-based C project with its own dependencies on obscure C projects scattered across the Internet, each with their own special snowflake build systems and their own dependency trees), etc. Nix is definitely the right direction (it could completely solve the monorepo/multirepo problem and dramatically simplify CI/CD and otherwise significantly improve software development), but it’s not very pragmatic. It badly needs some product leadership.

X6S1x6Okd1st 6y ago

Specific to NixOs, but running software that hasn't already been packaged for nix can be quite hard. The language is not simple and discovery can be quite lacking.

ywei3410 6y ago

When it’s hard to do something in Nix, it’s really hard. Let’s say you download a random binary which isn’t part of the Nix distribution — it is unlikely that you can run the binary; you may need to run ldd or nm to check the headers or construct the LD_LIBRARY_PATH manually. So many random build scripts assume certain things like cp exists in /bin/cp or use absolute paths (looking at you Python) that I tend to find I’m yak-shaving pretty often. The documentation for Nix… is special. I’ve never seen any configuration need to explain the fixed-point [1] in order to do something which should be pretty simple. On the other hand, when it works, it works brilliantly. I have projects where I want to fetch some random URL, or build some randomly generated C file; previously which I would have just said sod-it and checked it into the repository. Being able to share crafted environments ala direnv to colleagues and the continuous-integration is magical. Having per-project environment management which doesn’t require 3-4 tools like virtualenv, nvm, docker, docker-compose is really nice. [1] https://nixos.org/guides/nix-pills/nixpkgs-overriding-packages.html https://nixos.org/guides/nix-pills/nixpkgs-overriding-packag...

GlennS 6y ago

Speaking to NixOps in practicular, I've used quite a bit at previous jobs, and still use it for my personal stuff. It's very good and convenient (if you already know Nix), but it doesn't have a lot of maintainers so it's missing a lot of features compared to Terraform. For a lot of people these features don't matter, but at companies over a certain size they're probably be considered table stakes: * Not really a good story out of the box for teams, because the state file is just an SQLite database on your computer. Terraform has all sorts of helpful options for where to store its state file. There was some work in progress to improve this on NixOps last time I looked. * Doesn't support AWS load balancers. There is support for Azure load balancers though, so maybe this will come in the future? You can setup a load balancer separately and point it at your NixOps deployed instance, but meh. * Doesn't support AWS ECS/Fargate, which is a shame because that would be an excellent combination (building a customized NixOS docker image is very easy and space-efficient). * Doesn't support authenticating with temporarily assumed AWS roles. AWS "best practice" encourages using these. On the other hand, it does have one feature that Terraform doesn't: you can very easily build and deploy your code at the same time as your infrastructure. Whether it's actually a good idea to do so is up for debate, but it's certainly convenient. It's also usually a bit faster than Terraform I find.