I have tried to use it for C++, iOS, Python, Flutter, Docker, MacOS binaries, an Ubuntu container, MacOS, and NixOS. In every case it became a time sink that failed to work due to broken packages and convoluted code.
Core issues are that:
(1) To meet nix’s goal of declarative package management, everything in nix wraps software to create a bespoke interface for nix. But the documentation for the nix interface is extremely spotty and inconsistent, where it exists at all.
(2) The language is a mix between functional and shell code, to create a declarative spec. This means many mental gear shifts while reading. This is made even worse by the nixpkgs API being inconsistent, with case-specific variants of functions (eg to set a property on a package you might need to call a language-specific property setter, which is very confusing when a package is built with multiple languages)
(3) Many packages are broken or unsupported on one OS or the other.
Because of these, it means that you need to be a coder AND have deep Linux knowledge AND deep Nix knowledge to use it for an extended period of time.
And then:
(4) Nix does not cleanly integrate with the packaging for a language, or expects running an AOT tool to generate a bespoke Nix derivation from the standard tooling
I and others have complained about Nix being too difficult to use for years, but the Nix community instead is more excited about flakes, which are even more convoluted than existing derivations and metastasize the existing architectural issues in nixpkgs into countless decentralized packages that will now need to be refactored if someone tries to overhaul the design of nixpkgs.
From my perspective, nix flakes are like if Linux was struggling with adoption because its internal and user APIs were undocumented and frequently broken, and the kernel developers got really excited about moving all the drivers out-of-tree into separate repositories because that’s “best practices”.
A killer cross-platform and project / system package management system with hermetic build environments would be a godsend. But nix’s practical implementation of that is too badly done for me to have ever been able to use it for anything but the tiniest most specialized of projects, or as a partial package manager for macOS (where I still have to install things manually or use homebrew).
There are a great many things that are theoretically possible with Nix, but I don’t know anything that I could practically recommend it for.
> Many packages are broken or unsupported on one OS or the other.
Report them. There's thousands of packages. Efforts like Zero Hydra Fails help, but there's still a lot to fix. If you raise an issue, it will be prioritised, because we'll know someone actually cares about it.
Keep in mind that's compared to a small percent of those packages available in other systems where you're on your own - not much different than on nixos with a broken package.
The worst case that comes to mind was iOS development. In that case there was supposedly packaging available that leveraged the Xcode cli, but it had ceased to be maintained and once I started fixing stuff, I began running into even deeper issues that made me question whether it ever truly worked.
In other cases it was things like mach-nix not working for certain Python packages, and evidently a refusal to upstream something like mach-nix that tried to work with default Python packaging upstream, and the default Python API being a mess to work with.
Thus in the latter case while from the nix POV nothing in nixpkgs was “broken”, it working as designed left me choosing between investing large amounts of time to figure out how to implement a derivation for the third-party Python script I wanted to work on or dealing with third-party tools. And I expected all that to be a rathole too. I wasn’t looking to push some tooling on the third-party maintainer or develop something I’d just throw away, I wanted to add a relatively simple feature. As it was I wound up spending the free time I had troubleshooting package management and ran out of time to actually get work done. I did file an issue with mach-nix, but the person who helped me also ran into problems.
This kind of “brokenness in depth” is exactly what I ran into when I tried to troubleshoot and fix nixpkg’s iOS support over a few months.
I have actually contributed a couple packages back, and I wrote a brew-like derivation adapter that may or may not still work on one of my macOS devices that worked with standard macOS installers/install archives (copy to Applications folder), but that got broken by an upstream update and fixing it became involved. Iirc whatever I did do to fix it made it unsuitable to upstream, and when I did get another macOS device, I didn’t even try to use nix for applications that weren’t immediately supported.
Most recently I tried to create an Ubuntu container with USB forwarding under NixOS. Once again: bespoke solution, scant documentation, and GPT-4o got confused. I failed, and spent less time copying my files off and installing Ubuntu than I did trying to get it to work under NixOS.
So this isn’t just one-off packages being broken that a maintainer needs to fix. It’s a deeply pervasive thing with the entire nix ecosystem that requires the community to internalize a need to make things work obviously and on the first try for common use cases.
I don’t know anybody whose problem is “people want to pay me to work on nix with no other output product to the work other than more nix”, so I can’t recommend nix to anybody as a solution. You can’t solve a problem with more problems. And after the container incident, I’m truly lost as to what people ARE doing with nix besides just developing nix, because I thought it was supposed to be most popular in Devops contexts.
And yet the very last thing I would entrust to nix at this point would be a production service whose infrastructure needs to be completely understood and rapidly fixable, because the abysmal documentation means a minor outage could turn into a major catastrophe while people google for some obscure forum post or decipher nixpkgs layer by layer.
Yeah, that would be a problem for a few reasons, but I'd point that rant at Apple "releasing" incomplete and broken sources. This whole area has been changed massively recently by a few Darwin heroes and will be released in 24.11. It's also going to be much easier to maintain in the future.
So if you're interested, try the new apple SDKs in a couple months.
FTR, it solves quite a few of my daily issues, especially in DevOps contexts where brew is unusable.
> FTR, it solves quite a few of my daily issues, especially in DevOps contexts where brew is unusable.
Perhaps there needs to be more explicit scope communicated. Right now the nix(os) website advertises several use cases that it just doesn’t seem ready for (but this has been the case for ~5 years now, so I don’t expect it will ever be ready).
When I’ve tried asking eg “is this ready for flutter development”, I was told yes, then immediately ran into brick walls when I started trying to develop with it.
And when it comes to filing a bug report, then I feel (or the maintainers will feel) that I’m obligated to grab logs, put in a certain amount of effort, format everything accordingly etc etc.
It’s just an exhausting amount of mental complexity to deal with right now, to the point it’s hard not to say “just use docker” is the right answer. However brute force and wasteful that may be in comparison.
Improving the interaction with language ecosystems was one of the motivating reasons for how I approached the [rework][1] of Darwin support in nixpkgs. A lot of Rust stuff was simply impossible to build due to their SDK needs and how hard it was to override the SDK correctly, but that’s fixed now (with a few remaining cases that will be fixed in the final staging cycle before 24.11). I expect other ecosystems to benefit similarly, especially since Darwin support looks more like a native toolchain while still being built and provided by nixpkgs.
For example, Zed and Wezterm (previously failing intermittently on x86_64-darwin) now build on Darwin. Someone even has [Firefox building from source][2]. PyTorch will be able to support MPS, and MoltenVK will be able to use Metal 3 features if your system supports them.
A good summary of the pain points I have with Nix. I was introduced to it recently at DayJob because one of the engineers I work with is a huge advocate for it.
I think there's a good use case for a small subset of Nix + direnv to manage system packages for repositories. That's essentially what we use at DayJob - but all it does is install system packages necessary for a containerized workflow. However, even that level of complexity, even if it's just a small flake.nix and .envrc, can be cumbersome to end users and we actively seek to hide away that complexity as much as possible because anyone not a Nix expert that is presented to work with Nix is entering a deep rabbit hole of complexity that is probably ultimately unrelated to the problem they are trying to solve.
Part of this I think is a branding and documentation issue with Nix. As a counterexample: I work with Argo a lot and they handle this sort of situation better. There is ArgoCD, Argo Workflows, Argo Events, and Argo Rollouts. They are all under the Argo umbrella that do distinctive things with clearly demarcated roles. Unlike Nix, I never get confused when I'm searching for ArgoCD related docs. I don't have to worry that I'm going to happen on Argo Rollouts related stuff and somehow not understand that Argo Rollouts is not the piece of Argo that I'm trying to use right now. The lines between each of the technologies are clearly demarcated and there is no confusion about the best way to do XYZ in each of them.
Not so with Nix - if I'm new to Nix and I'm looking up how to structure something in a flake, not only is there different setups/configs for a build tooling setup vs a package management setup, but even within a build tooling setup for instance there are probably 4-5 canonical different ways to configure things, all with a ton of decisions. Heck, if I'm new to Nix it is probably not even immediately obvious that I should be doing it with a flake instead of The Old Way, and I might even start implementing something using The Old Way before finding out buried in some Github issue from years ago that I'm Doing it Wrong
Thing that makes Nix amazing: It's infinitely customizable and welcomes that philosophy
Thing that prevents Nix from succeeding: It's infinitely customizable and welcomes that philosophy
TL;DR Nix favors configuration over convention, oftentimes to its detriment
Final footnote. I am writing this on a personal x86 machine managed with nix-darwin. It functions, but the amount of nondeterministic calls out to homebrew and kludges required for it to work essentially defeats the purpose of managing the machine declaratively in the first place. All of the following extremely popular softwares available in nixpkgs - 1Password, VSCode, Firefox, Docker Desktop - don't work out of the box on this machine and require either compiling the package yourself, jumping through some hoops to get it to work with MacOS code signing, or require you to just entirely ignore the Nix aspect and have Nix shell out to Homebrew. There are also quite a few binaries of packages that are simply unavailable in Nix.
Yes, I know that and you know that. But GP wanted to install the package and move on with his life instead of debugging a connection that failed with no indication why on an unfamiliar OS.
How was he supposed to know to ignore those instructions and go to a completely different set of docs and search for "programs.adb.enable"?
Instead he gave up and switched to another distro where you install the package and it Just Works™. Even though NixOS's model is conceptually better, it loses out on tons of potential users because of usability problems like this.
IMHO, a couple of major issues with this are some properties of Nix documentation websites, that make them not popup in search engines on certain queries.
In this particular case it would be great to have "nixos Android SDK" or "nixos adb" return either a hypothetical page like "NixOS.org/programs/adb" or at least "wiki.NixOS.org/pages/Android-SDK". There's a problem with "nixos.wiki" showing up instead. If both are controlled by the community, "NixOS.wiki" should instead do permanent redirects to "wiki.nixos.org" so that search engines would correctly show it.
Somebody really needs to work on this, this hurts the adoption A LOT.
Edit viraptor in the sibling said it is the fault of user they didn't use documentation. No, it is not. We've known for long that global search is much better interface to docs, the approach with custom UX and per-feature search (in Nix: programs, services, setup instructions, wiki, options, etc) just sucks and needs to support the efficient one.
Sometimes you just need to put in some work and understand what you're doing. The author needed to search for "adb" in the docs, not the whole attribute path. With the errors, they could debug the issue like they would on any other system.
But that search is for packages themselves and is correct - that's how you install it. It's not going to tell you about the configuration just like it doesn't for nginx, postgresql, or many other packages. Sometimes you "have to be this high to ride", or use a simpler system - but that comes with its own issues.
(Although in this very specific example it could just to make life easier - I'll send a PR next week unless someone does it first)
Why is this extra completion acceptable? On Debian I install the package adb and get the udev rules with it. I just need to connect a device and run adb commands.
Core issues are that:
(1) To meet nix’s goal of declarative package management, everything in nix wraps software to create a bespoke interface for nix. But the documentation for the nix interface is extremely spotty and inconsistent, where it exists at all.
(2) The language is a mix between functional and shell code, to create a declarative spec. This means many mental gear shifts while reading. This is made even worse by the nixpkgs API being inconsistent, with case-specific variants of functions (eg to set a property on a package you might need to call a language-specific property setter, which is very confusing when a package is built with multiple languages)
(3) Many packages are broken or unsupported on one OS or the other.
Because of these, it means that you need to be a coder AND have deep Linux knowledge AND deep Nix knowledge to use it for an extended period of time.
And then:
(4) Nix does not cleanly integrate with the packaging for a language, or expects running an AOT tool to generate a bespoke Nix derivation from the standard tooling
I and others have complained about Nix being too difficult to use for years, but the Nix community instead is more excited about flakes, which are even more convoluted than existing derivations and metastasize the existing architectural issues in nixpkgs into countless decentralized packages that will now need to be refactored if someone tries to overhaul the design of nixpkgs.
From my perspective, nix flakes are like if Linux was struggling with adoption because its internal and user APIs were undocumented and frequently broken, and the kernel developers got really excited about moving all the drivers out-of-tree into separate repositories because that’s “best practices”.
A killer cross-platform and project / system package management system with hermetic build environments would be a godsend. But nix’s practical implementation of that is too badly done for me to have ever been able to use it for anything but the tiniest most specialized of projects, or as a partial package manager for macOS (where I still have to install things manually or use homebrew).
There are a great many things that are theoretically possible with Nix, but I don’t know anything that I could practically recommend it for.