[rgoulter]

My experience with Nix and NixPkgs is that 95% of the time it's fine. That 5% is a real PITA.

I think nix isn't as useful for developers using it to setup their workstation compared to for operations setting up deployment environments. -- I like that I can just run "nix --install myPackages" and have the exact, up-to-date versions of software installed... but, it's not often that I need to run this. (The up-to-date versions thing is nice). -- Maybe this will be more compelling for stuff like GitHub Codespaces, and other ephemeral machines?

(EDIT: and nix-shell is cool and very pure, but looks to me like people are just fine using images of development environments/toolschains with VMs or Docker. etc.).

NixOS itself does feel very different to other OSs. I think people discount how much trouble they run into on other OSs. Partly because other OSs have larger communities, and advice will often apply across multiple OSs. With NixOS, there's a higher requirement for understanding of what's going on; and it's not obvious that the benefit from doing this is worth it.

[lilyball]

On the contrary, I find it super helpful to set up my workstation. I don’t use any other package manager on macOS these days, everything is Nix, fully declarative with a small script that basically does `nix-env --install` (but with the flags to replace my current environment wholly, and with some helpers around showing what changed). I can then just sync my config between my machines and run my script and get identical setups on every machine I use, and I can update all of my packages at once just by running `nix channel --update` followed by invoking my script again.

And there’s a bunch of utilities I use rarely so I don’t even keep them installed, since I know I can just `nix run nixpkgs.hello -c hello` if I ever want to run them.

And then for a work project I set up a custom derivation that I can use when I need to run the occasional scripts that require the custom ruby and python environment, so I can just run e.g. `nix run nixpkgs.my.env -c pod install`. This way I’m not even polluting my global environment with this stuff the way the work scripts expect. And I’m currently working on formalizing this into Nix derivations in the work repo directly (in an attempt to convince my coworkers that we should all use Nix).

[rgoulter]

"nix is useful for getting the same version of programs on different computers". This is obviously useful to have.

Say for the use-case of "I have a macOS laptop, and I use Arch Linux on a different computer". I can't genuinely recommend nixpkgs as better than just running "brew install..." and "pacman -S" (and whatever AUR tool is in vogue). -- Yes, once you know what you're doing and have a configuration, nixpkgs is nicer. But it's not as if the good-enough alternatives are too hard.

When there are more hurdles to getting the bleeding edge (like on Amazon Linux or whatever), I appreciate how much easier it is to just "install nix, install my packages". But even then, installing a recent version of tmux or fish or whatever is a quick search and a few commands away. (Which isn't that much if you only have to do it once every few months; and/or note how to do it in some script or markdown notes).

[lilyball]

I don't understand the "I have a macOS laptop, and I use Arch Linux on a different computer" claim. If anything that's an even better time to use Nix, because it means I only need to know one package manager instead of two. The setup I currently use on macOS could be dropped onto a Linux machine and I expect it would work with zero changes there, or I could switch over to home-manager (probably a good idea, I just haven't done it for historical reasons). And if I don't have a setup yet I could just use `nix-env -iA nixpkgs.pkgname` to install stuff the way people usually get started with Nix.

[patrec]

> I think nix isn't as useful for developers using it to setup their workstation

Trust me, if your development setup is non-trivial (bunch of services maybe in different languages maybe written by different teams) it absolutely is, and is one of the areas where you can get the biggest productivity wins by using nix.

[ashtonkem]

In my experience, how good of a time you’ll have developing in Nix is incredibly tied to what you program in. Last time I tried Ruby was a real nightmare, and I never did manage to get Ruby on Rails to work correctly.

[p_l]

I had the same experience - and to make it worse, I was trying to integrate RubyMine into it.

At some point I managed something that could be launched from nix-shell, only to lose it soon after in FS failure.

[ianai]

Sounds like a good OS for a computer cluster.

[wwright]

I think it’s interesting to compare it to Kubernetes. K8S has more functionality at the cluster level and a stronger ecosystem, but Nix has a much more well-founded “core”, IMO.

Both are declarative by default and easy to reproduce.

Hopefully we’ll see them converge in the future.

[remify]

It's how they used it at my old job. You could deploy nix with the libs needed for the compute part.

[abathur]

I agree with most of this, but wanted to comment on the "developer environment" part. TL;DR: I feel like you're under-valuing this part?

> I think nix isn't as useful for developers using it to setup their workstation [...] I like that I can just run "nix --install myPackages" and have the exact, up-to-date versions of software installed... but, it's not often that I need to run this.

This might be idiomatic to me (i.e., the devices I use; how; my level of anxiety; etc.) but I have (historically) found OS reinstalls and system moves disruptive.

Over time, the work, documents, downloads, config changes, cruft, old apps and such on a system all congeal into a big blob of system state. To move with confidence, I ended up with a few choices: 1) have the old system runnable as a reference so that I can jump but have it as a reference every time I encounter something that's missing or misconfigured, 2) manually inventory everything on the system to triage what needs to be carried forward and what is crap, 3) copy everything on the system and pretend I'll take the time to do number #2 later (ha! in reality I'll just accumulate multiple nested copies stretching back decades!)

Adopting Nix enabled me to declare my personal essentials, and per-project essentials. This got me close enough to confident I can quickly prepare a fresh device that it motivated me to close most of the remaining gaps on macOS. Instead of feeling like it'd take me days+ to get back to full productivity on a clean device, I know I just need an hour or two.

This confidence liberates me from lot of gnawing everyday anxieties about (i.e., infinite permutations of how inconvenient it would be to lose my system at [already stressful moment where I'm under pressure to deliver something]).

> looks to me like people are just fine using images of development environments/toolschains with VMs or Docker. etc.

I used to be in the VM (virtualbox + vagrant/chef/shell) camp. I was net-happier with that than single-system state and things like virtualenv, but on a laptop I'm not very keen on the extra resource use and performance penalty, and over time I still found one shift or another (virtualbox/vagrant updates, chef cookbook updates, VM image updates, or a VM image that stops publishing) created a fairly regular drumbeat of unexpected, low-leverage debug time.