I've tried nix-darwin a time or two in the past. Every few years when homebrew makes a "hostile" change and I get upset I consider trying it again (now most recently with changes to gatekeeper). I think I'll get to doing so in the next year or so.
But I think just in fairness, the comparison here for flakes should be to Homebrew bundles. My packages are managed in a bundle: https://github.com/Julian/dotfiles/blob/main/Brewfile and then locked by a lockfile: https://github.com/Julian/dotfiles/blob/main/Brewfile.lock.j... and installing is just `brew bundle install`. All native Homebrew functionality. In practice I have never had an issue with non-reproducible builds across my machines (partly because the tendency on macOS is to run the latest versions of things and stay up to date).
(But again I do find nix-darwin interesting to try for other reasons.)
A useful way to frame this isn’t “is it worth tens of hours to avoid a future reinstall” but “where do I want my entropy to live”. You’re going to invest time somewhere: either in a slowly-accumulating pile of invisible state (brew, manual configs, random installers) or in a config that you can diff, review and roll back. The former feels free until you hit some cursed PATH/SSL/toolchain issue at 11pm and realize you’ve been paying that tax all along, just in tiny, forgotten increments.
I think where Nix shines isn’t “one laptop every 6 years” but when your environment needs to be shared or recreated: multiple machines, a team, or a project with nasty native deps. At that point, nix-darwin + dev shells becomes infrastructure, not a hobby. You don’t have to go all-in on “my whole Mac is Nix” either: keep GUI apps and casual tools imperative, and treat Nix as the source of truth for the stuff that actually blocks you from doing work. That hybrid model matches what the article hints at and tends to give you most of the upside without turning your personal laptop into a second job.
> The consequence is me, spending a few hours debugging my environment instead of writing code.
But then I also see this:
> I’ve spent a lot of time recently moving my entire workflow into a declarative system using nix.
I can see how this can be beneficial for someone who switches systems very often, reinstalls their OS from scratch very often, or just derives a lot of pleasure/peace of mind knowing that their dev env is immutable.
I change computers once every 6 years or so, maybe more. To me this looks like exchanging a couple (hypothetical) hours of debugging 6 years in the future by tens of (guaranteed) hours trying to climb up the nix learning cliff.
I am happy that it works for the author though, and knowing that it's possible is good in case my particular development circumstances change.
Long-time (by now) Nix user here. It's even worse than a few hours of debugging. In my experience it requires continuous maintenance, options tend to be deprecated and moved around on a regular basis (at least in NixOS and home-manager), things like NeoVim break regularly as a result of friction between the immutable world and a lot of plugins expecting a mutable world, etc. I do install my Mac from scratch every 6 months or so (I like a clean system), but with a dotfiles repo and Homebrew, it takes me about an hour to set everything up again, which is far less time than maintaining a Nix-managed system.
For me Nix/NixOS is by far the most effective for deploying servers, development VMs, etc. I do this regularly, so it pays off - I have a familiar environment completely set up in minutes. Another place it pays off, even on macOS, is for development environments, especially if you have to pull in a lot of native dependencies (which can happen in mixed Python + C++ projects, mixed Rust + C/C++ projects, etc.).
Nix shines in all difficult cases, like setting up complex cross-compilation environments, building for old glibc versions, etc. You set it up once and then it's really easy for yourself and other project contributors to get the same build environment.
Like any tool, a good engineer knows when to apply it.
Nix is not worth it if all you want is configuring your home computer. The learning curve is steep and has a tall onboarding cliff.
The only way you get positive ROI from Nix is either you enjoy the journey, or you use it to do more than just managing a single computer: you manage a fleet, you build thin application container images, you bundle all your software, you have devshells, repeatable tests and deploys, etc. It's the same tool for all of them.
Nix is a wonderful technology. But I would not argue it is practical if you can afford "just fix it when it breaks". A nix setup more/less requires you to pay all the cost up front.
I appreciate putting in the effort now so that I don't have to later for stuff like declarative dev environments. It's really nice to not have to copy-and-paste installation instructions from a README. -- I did like the point: until you've felt what a comfortable design is, you cannot imagine it.
In the six years you are using your computer, do you ever expect to run into versioning issues and conflicts? Homebrew packages conflicting with local packages, something you compile give needs a different python/ruby/node/rust/whatever version that you have locally installed, you want to quickly try out a new package or upgrade without changing your system but have the option of rolling back safely, need to quickly install a database, want to try out a new shell and shell config but don't brick your system and have the option to roll back, etc. Nix gives you all of that and more for a one-time setup cost. Your argument is correct only if you expect to never change anything on your computer for the 6 years. But if I think about how often I have fought with homebrew or some kind of versioning/path/binary conflicts in the past then the investment in nix has paid off exponentially.
It's also about peace of mind like you said. Before nix I sometimes felt anxiety installing or upgrading certain things on my computer. "Will this upgrade break stuff?" - and often it did and I'd have to spend the next few hours debugging. With nix I don't worry about any of that anymore.
That's mostly solved with env managers for python/ruby/node/..., takes at most a few minutes to fully set up and learn, and doesn't get constantly broken by macOS updates.
Even for things like trying out a new shell you can temporarily move the dotfiles somewhere and restore them back and it still takes less time than converting everything to Nix.
But now you’re stuck with Python. Nix enables trivially simple dev environments that are completely heterogenous. This gives you a powerful form of freedom because it literally opens up the entire software universe to your dev environment in a confidence inspiring way. Not to mention things like parameterising anything you use reliably and setting up environment variables, shell scripts, database service whatever you want. Also integrates with tools such as UV really well. Yes, the language is terse and difficult but once you know it, it’s liberating, and makes you a better software developer in my opinion because you now have a high-end full workshop rather than a small toolbox.
This is my feeling too. Nix is a relatively high time investment for a tool that tries to do everything, when you might not need or want everything and using the specific language’s tooling is more than sufficient and quicker. It takes a few minutes to install and do `uv sync`, or `nvm install`, or whatever, on a repository on a new computer, and it just works. Until Nix gets there, and I’m skeptical it will because of the “purist” mindset a lot of people in the community have, it’s hard to justify it.
I have experienced a positive return on investment from using Nix Darwin and devenv.sh since getting a new Mac two years ago. Did not spend too much time learning neither.
> I change computers once every 6 years or so, maybe more. To me this looks like exchanging a couple (hypothetical) hours of debugging 6 years in the future by tens of (guaranteed) hours trying to climb up the nix learning cliff.
yes, it sounds like it's not worth it for you -- you will have to spend a significant amount of time converting your system to do things "the nix way". you can try to do this incrementally, but it's a time sink, and really easy to get stuck bikeshedding instead of doing work.
for me, it feels like a near equal trade-off between debugging nix, or debugging some random env issues that pop up. i know nix, claude code "knows" nix, a lot of other people online know nix. random env issues are random, and yield worse results on google, and frankly are much more frustrating to the point i would rather spend more time with nix than deal with them. maybe a very weird view.
only thing i'd add is mas for mac app store apps you want to ensure are installed but otherwise i run pretty much the same setup.
When i install a fresh macos i have two commands to run - install nix using the determinate systems installer, then apply my nix config.
It's not quite as streamlined as nixos but good enough.
My biggest remaining pain point is dev envs - i've been leaning into adding a flake in each project, so for example i have a single project that's written in scala 2.13, when i cd into that project dir, the correct jvm version, sbt, intellij etc are installed, some useful env vars and shell aliases etc. - that's all great (i haven't felt the need to adopt denenv.sh or flox yet) but i do find myself wanting a devcontainer sandbox workflow more often these days (blame cli coding "agents"), i lean on vscode for that rather than nix so far. In python (where i spend a lot more time) uv loses a lot of value in nix and i don't like that.
I did this for a while but MacOS updates broke Nix often enough that I usually would spent some time every week reinstalling it. I still use Nix for dev environments because it is great but Nix still breaks sometimes.
I also really wanted to like the declarative homebrew configuration but it also often didn’t work as expected for some configurations and had a lot of leaky abstractions that straight up just broke sometimes.
If I ever go back to managing my Mac with nix I would probably just do a home-manager setup and just install most of the applications imperatively.
Given this was using an intel based machine around the time when the switch to arm came so a lot of breakage also stemmed from that.
I still use nix to handle my homelab.
My setup up on my Mac is as follows:
- Orbstack
- NixOS machine run in orbstack
- My whole dev environment is run from this container and is very transportable
- GUI apps are installed on my Mac using the App Store or homebrew etc. but I try to reduce the amount of installed applications
- if I have to install something that I don’t want to install but have to, I try to do it in a UTM machine.
Ive been using nix-darwin for over a year now after using nixos with flakes for a bit. I now have a singular repo with multiple machine configurations. Nixos for my home server, nix darwin on a macbook air and a nix darwin with a work config. This allows me to have common programs on all machines but also overlay some specialised packages and programs in certain environments. After climbing the initial mountain, its been very satisfying and things just work. My work laptop died recently and I was able to be fully up to speed in a fraction of the time it would have taken me otherwise.
It would be nice to set up immutable config down to the granularity of a git commit, sharing it as a single file, and be able to reproduce that setup on anyone's machine. Instant onboarding and mirrored production (barring secrets).
Recent developments have seen the creation of bootc images for non-Fedora distros too, and at this point I've seen quite a few cool arch-bootc custom images, completely customized to the author's desires. See: https://github.com/bootcrew/, https://github.com/tartaria-dev/tartaria
For me, this is the holy grail. Every time I switch laptops, I lift all my config files and such over, but there's always so many system level configs and other things that you have to go and manually fiddle. On top of that, some apps don't really behave well when you just move config files to e.g. under a different username etc. Would be nice if there was a comprehensive solution to this problem, need to try nix-darwin out.
nix-darwin is essentially this. I have a small bootstrap script to install Xcode CLI and Nix, git clone my dotfiles and activate the config. That in turn sets up the system, also installs Homebrew, installs apps from the App store and sets up all my configs. The only thing I need to do after is sign into some accounts.
I haven't used Nix yet, but I have done exactly this a number of times with Guix now. I assume Nix has the same capabilities. In Guix you can specify a home configuration that includes packages, configuration files, and running services all in one manifest.scm file. If you want to make sure that it's isolated from whatever else is set up on the system you can launch that manifest in a container with a single extra flag
this is basically the purpose of nix flakes, which take in inputs (usually git repositories) and provide outputs (compiled files, docker images, etc). it's a pain to get going, but not tremendously difficult with some googling. It's a lot easier with AI as well.
Installed nix-darwin on 26.0, on a fresh M4 air. I have updated since updated macos to 26.2 through the normal method, no wacky nix stuff there. no issues. no clue on major version changes, but nix-darwin is essentially the nix config language parsed to then run the necessary set of scripts.
I’m using nix to set up both my dev laptop (macOS) but also my self-hosting/homelab (NixOS). It works really well, and nice to have one way to set stuff up. And they are both synced up with the stuff I want to be mirrored across systems.
I see these kind of posts like using Gentoo, cool that some people are having fun, not for me, using computers the mid-80's I have better yaks to shave.
I am critical as with any technology (see my comment about Nix in another thread here), but Nix is profoundly not using computers the mid-80's way. It is more future technology, where a system is immutable, fully declaratively defined, has atomic updates/rollback, etc. It's the direction things are going, see e.g. macOS sealed system volumes, Fedora Silverblue, etc. It's just that it still has a very large number of sharp edges, not so great documentation, lack of static typing, etc.
Nix may not be the tech that replaces everything, but at the very least it is and has been an important exploration vehicle for declarative configuration, immutable systems, etc.
Interesting, and good luck to OP. I feel a little clickbaited, cause I was hoping for a port of stateless infra (although it may be of little use on a (dev machine :p) [1]
I tried nix-darwin for half a year, and ran into endless problems: poor docs, huge default disk usage, non-trivial to customize, etc. After 6 months, I eventually went back to a mix of Homebrew and mise, which does most of what I need for <1% of the hassle.
I still believe something like nix is the future of building software, I'm just not sure it'll be nix itself.
But I think just in fairness, the comparison here for flakes should be to Homebrew bundles. My packages are managed in a bundle: https://github.com/Julian/dotfiles/blob/main/Brewfile and then locked by a lockfile: https://github.com/Julian/dotfiles/blob/main/Brewfile.lock.j... and installing is just `brew bundle install`. All native Homebrew functionality. In practice I have never had an issue with non-reproducible builds across my machines (partly because the tendency on macOS is to run the latest versions of things and stay up to date).
(But again I do find nix-darwin interesting to try for other reasons.)
I think where Nix shines isn’t “one laptop every 6 years” but when your environment needs to be shared or recreated: multiple machines, a team, or a project with nasty native deps. At that point, nix-darwin + dev shells becomes infrastructure, not a hobby. You don’t have to go all-in on “my whole Mac is Nix” either: keep GUI apps and casual tools imperative, and treat Nix as the source of truth for the stuff that actually blocks you from doing work. That hybrid model matches what the article hints at and tends to give you most of the upside without turning your personal laptop into a second job.
> The consequence is me, spending a few hours debugging my environment instead of writing code.
But then I also see this:
> I’ve spent a lot of time recently moving my entire workflow into a declarative system using nix.
I can see how this can be beneficial for someone who switches systems very often, reinstalls their OS from scratch very often, or just derives a lot of pleasure/peace of mind knowing that their dev env is immutable.
I change computers once every 6 years or so, maybe more. To me this looks like exchanging a couple (hypothetical) hours of debugging 6 years in the future by tens of (guaranteed) hours trying to climb up the nix learning cliff.
I am happy that it works for the author though, and knowing that it's possible is good in case my particular development circumstances change.
For me Nix/NixOS is by far the most effective for deploying servers, development VMs, etc. I do this regularly, so it pays off - I have a familiar environment completely set up in minutes. Another place it pays off, even on macOS, is for development environments, especially if you have to pull in a lot of native dependencies (which can happen in mixed Python + C++ projects, mixed Rust + C/C++ projects, etc.).
Nix shines in all difficult cases, like setting up complex cross-compilation environments, building for old glibc versions, etc. You set it up once and then it's really easy for yourself and other project contributors to get the same build environment.
Like any tool, a good engineer knows when to apply it.
The only way you get positive ROI from Nix is either you enjoy the journey, or you use it to do more than just managing a single computer: you manage a fleet, you build thin application container images, you bundle all your software, you have devshells, repeatable tests and deploys, etc. It's the same tool for all of them.
Nix is a wonderful technology. But I would not argue it is practical if you can afford "just fix it when it breaks". A nix setup more/less requires you to pay all the cost up front.
I appreciate putting in the effort now so that I don't have to later for stuff like declarative dev environments. It's really nice to not have to copy-and-paste installation instructions from a README. -- I did like the point: until you've felt what a comfortable design is, you cannot imagine it.
It's also about peace of mind like you said. Before nix I sometimes felt anxiety installing or upgrading certain things on my computer. "Will this upgrade break stuff?" - and often it did and I'd have to spend the next few hours debugging. With nix I don't worry about any of that anymore.
Even for things like trying out a new shell you can temporarily move the dotfiles somewhere and restore them back and it still takes less time than converting everything to Nix.
yes, it sounds like it's not worth it for you -- you will have to spend a significant amount of time converting your system to do things "the nix way". you can try to do this incrementally, but it's a time sink, and really easy to get stuck bikeshedding instead of doing work.
for me, it feels like a near equal trade-off between debugging nix, or debugging some random env issues that pop up. i know nix, claude code "knows" nix, a lot of other people online know nix. random env issues are random, and yield worse results on google, and frankly are much more frustrating to the point i would rather spend more time with nix than deal with them. maybe a very weird view.
When i install a fresh macos i have two commands to run - install nix using the determinate systems installer, then apply my nix config.
It's not quite as streamlined as nixos but good enough.
My biggest remaining pain point is dev envs - i've been leaning into adding a flake in each project, so for example i have a single project that's written in scala 2.13, when i cd into that project dir, the correct jvm version, sbt, intellij etc are installed, some useful env vars and shell aliases etc. - that's all great (i haven't felt the need to adopt denenv.sh or flox yet) but i do find myself wanting a devcontainer sandbox workflow more often these days (blame cli coding "agents"), i lean on vscode for that rather than nix so far. In python (where i spend a lot more time) uv loses a lot of value in nix and i don't like that.
I also really wanted to like the declarative homebrew configuration but it also often didn’t work as expected for some configurations and had a lot of leaky abstractions that straight up just broke sometimes.
If I ever go back to managing my Mac with nix I would probably just do a home-manager setup and just install most of the applications imperatively.
Given this was using an intel based machine around the time when the switch to arm came so a lot of breakage also stemmed from that.
I still use nix to handle my homelab.
My setup up on my Mac is as follows:
- Orbstack
- NixOS machine run in orbstack
- My whole dev environment is run from this container and is very transportable
- GUI apps are installed on my Mac using the App Store or homebrew etc. but I try to reduce the amount of installed applications
- if I have to install something that I don’t want to install but have to, I try to do it in a UTM machine.
1: https://github.com/devmatteini/dra
There's of course Fedora Silverblue / Fedora Bootc with https://universal-blue.org/ and https://blue-build.org/ being good examples.
Recent developments have seen the creation of bootc images for non-Fedora distros too, and at this point I've seen quite a few cool arch-bootc custom images, completely customized to the author's desires. See: https://github.com/bootcrew/, https://github.com/tartaria-dev/tartaria
This is just procrastination.
Nix may not be the tech that replaces everything, but at the very least it is and has been an important exploration vehicle for declarative configuration, immutable systems, etc.
1: https://grahamc.com/blog/erase-your-darlings/
I still believe something like nix is the future of building software, I'm just not sure it'll be nix itself.