3 ms·

I don’t think NixOS (or possibly Guix, never used it) provide any significant value-add to development, that you couldn’t get via using nix as a built tool on a

• toastal 2y ago
  The value add is the whole OS, top-to-bottom is now an expression of its declarative config which the others have you mutate files for config that inevitably go stale. Having used it for a couple years now, it’s hard to express how much more comfortable I am hacking on parts of my system I don’t even understand that well since rollbacks are trivial & patches can be declarative so I can run those upstream fixes or patch things I don’t like without worry. On other distros, had I bothered to compile something for a patch rather than just waiting (or hoping) for it, it wasn’t easy to maintain new updates to that package while maintaining those patches & it was a real hassle to manually compile it. Versus Nixpkgs where I update & if there is a new package version it automatically gets recompiled according to the patches I have declared in my system’s config. These same principles apply to development as well. Once you get the hang of it, you can customize any environment just like your system. It feels weird to value Nix in a development environment & not see it as useful for your system. …It also helps that Nixpkgs has more packages than even the AUR (that said, AUR being self-hosted is great instead of relying on Microsoft which throttles me all the time).
  • ratorx 2y ago
    NixOS of course has benefits as an OS, but I don’t think any of them are specific to development. I also think the tradeoffs are worth considering. You lose a few things by using NixOS: * ability to run/depend on non-nixos software (without packaging yourself) * you have to use the declarative config system, which can be annoying and slow if you want fast iteration to get something working * Patching support is nice, but I don’t really have a use case for it generally for system dependencies (which I like to keep relatively lean, and close to distro upstream). For a development dependency, it may be different but you don’t need NixOS to benefit from patching there (nix shell is good) Moreover, especially with nix shell (for project dependencies) and home-manager (for user tool configuration), I rarely have a need for software installed globally. I use Debian and the only system level things I configure are automatic updates, backups and Prometheus. Systemd config is already pretty declarative, which only really leaves user management as something that could be more declarative. You can get a pretty good setup using a bare git repo version controlling /etc, without needing all the extra complexity of NixOS. I keep a ~50 line text file with rough instructions and a list of packages. I guess it gets a bit more complex if you run a gui desktop, but these are generally very well-trodden paths in big distros and fairly streamlined. I haven’t used desktop NixOs, but given the shitshow of desktop Linux, it seems like something that may get complicated in Nix? The familiarity argument is reasonable, but also NixOS module system is pretty radically different to Nix the package manager/build system, so it only partially applies. Even adding home manager to the party, only the base concepts of the module system really apply; you end up having to relearn a set of new modules. To sum up: * It becomes way more difficult to do common development-related stuff that you may need * The majority of the development benefits can be achieved without NixOS. * The flexibility of being able to opt to use Nix and the degree to which you do so (either just shell providing dependencies, or whole the build system being Nix, or even using something completely different) or not is also something that may be very useful for development. * The familiarity argument is decent, but it’s different enough that you basically have to learn a lot of stuff independently.