4 ms·

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

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.
- rgoulter 4y ago
  > 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.
  - pxc 4y ago
    .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.
    - JamesSwift 4y ago
      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.
  - winterqt 4y ago
    > 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.
- pxc 4y ago
  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.

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.

rgoulter 4y ago
> 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.
- pxc 4y ago
  .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.
  - JamesSwift 4y ago
    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.
- winterqt 4y ago
  > 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.
pxc 4y ago
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.