I've just migrated from a 4 year old Macbook to top of the line M3 Max. My previous Macbook had multiple kernel extensions, lots of customisation and homebrew apps and such. I was convinced that I'd spend a significant amount of time setting it up again - so I'd made some bash scripts in preperation to reinstall my homebrew stuff etc.

So upon receiving my macbook I used the migration assistant and ticked everything, and to my surprised I've spent less than an hour getting this new machine up to speed. It moved everything including all my settings, apps, configurations for those apps etc. The only issues I've had is docker didn't move across, and I've had to manually download universal binaries of a few intel apps. It has been completely flawless.

I don't see the value add for the use-case you describe of machine migrations when Apple's tool for this works so well.

I agree, I'm not getting new computers more than once a year, at most. Setup time doesn't seem like something I should optimize for.

I would argue the benefit is also it’s declarative, done forever, and your machine becomes relatively bulletproof.

Dev environment issues are a thing of the past, once you’ve defined your configuration.

If something is broken with a package, I don’t have to figure it out myself —- I just rollback, wait for someone to fix it upstream in nixpkgs and pull down the patch later.

At least in my opinion, the leverage here isn't about directly saving time in some hypothetical universe where you set up new devices every week.

It's about confidence in your ability to quickly bootstrap a productive system and the relative freedom/security that flow from knowing it.

When you know you can be productive this quickly without access to a backup or a working device, you have relative freedom and security from a decent spectrum of manufacturing defects, hardware failures, disasters, accidents, thieves, and so on.

> The primary benefit is that when I get a new macOS machine, it's only three steps to having ALL my apps, configurations, etc. exactly as they were before

This is the same for macOS? I’ve done that twice in the last couple of years and it was just a matter of letting the migration assistant run and letting Homebrew install the list of packages exported from the old system.

This is not to say anything negative about Nix, only that this particular point doesn’t seem like a big selling point for something I do every few years.

For single-user single-device scenarios, you probably won't find Nix much better than brew or apt. Declarative infrastructure isn't very necessary when you're the only person running your software. With multiple devices, you at least want a way to automate your build process. Bash scripts and Makefiles work fine, but they both fail silently and won't work consistently across devices, OSes or even architectures.

Nix smooths that out, which is great for a single user with multiple devices but even better on teams. Instead of coordinating devices individually, you can update Nix environments and push them out to everyone at once. The build environment is self-contained, isolated and updated silently alongside the rest of your repo. On larger teams, that saves a lot of configuration headache.

> these are shared Nix configurations between macOS, Linux, and WSL on Windows

This is the "killer app" of Nix for some people. I've got a lot of machines, spread out between a variety of usecases. With Nix, I can have individual module files for my desktop apps, my gaming software and my terminal configuration, then link them into the various machines that need it. Once it's fully set up, you can essentially manage the environment of dozens of different machines in a single Git repo.

Nix will frustrate people because it doesn't offer a lot of imperative or immediate solutions to things. If you can handle the learning curve though, you'll be hard-pressed to find a more comprehensive package management solution on any OS.

Despite how the learning curve keeps the Nix community relatively small (it's grown a lot since 2021 actually) nixpkgs has assimilated like 90% of OSS. Learning Nix is hard, but once you know enough Nix to be productive it's a huge enabler.

How does Nix manage Homebrew? Haven’t heard of that. Does it make Homebrew declarative somehow?

Unclear at what level you're asking, but Mitchell's comment identified it as a nix-darwin feature, and you can see how he's using it in the config he linked at https://github.com/mitchellh/nixos-config/blob/b73a16fc918c5...

nix-darwin supports managing your Brewfile.

The docs[2] are very helpful!

[1]: https://github.com/Homebrew/homebrew-bundle

[2]: https://daiderd.com/nix-darwin/manual/index.html#opt-homebre...

Here's my flake that does it: https://github.com/dustinlyons/nixos-config/blob/main/flake....

What's the benefit vs a restore from backup step which also restores your data in addition to apps and configs (and avoids any network)?

In exchange for having taken the time to understand and declare exactly what you depend on to be productive (and nothing else), you get to start ~productively-fresh instead of living in a cargo cult of whatever unexamined arbitrary state and executables were present at your last backup.

It also means you aren't completely out of luck if you get lazy and don't test your backups for 6 months only to find out they stopped working after you ran some `blah blah update/upgrade` command.

This isn't veggies, so what's the actual benefit of freshness?

Also not clear on the backup risk - why would a disk snapshot stop working because you've updated with blah?

I guess having your config as a text file in a public repo instead of a multi GB private file can be nice.