5 ms·

I see this: > 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 t

by otikik 10mo ago

I see this: > 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.

loveparade 10mo ago
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.
- trinix912 10mo ago
  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.
  - yladiz 10mo ago
    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.
    - rgoulter 10mo ago
      I think the comparison is "X-as-code", like with Terraform and other tools. If you just want a throwaway VM, it's straightforward to create one through the UI cloud console. Whereas, terraform is nevertheless still a useful tool to use to manage VMs. For stuff like installing development dependencies.. it's maybe not difficult to copy-and-paste instructions from a readme, but solutions like devcontainers or Nix's development shells can be useful even if costing more overhead.
      - yladiz 10mo ago
        Of course. I wouldn’t say that Nix is a tool without much use or merit, because setting up development environments can be a huge pain and I understand why some people would use it and prefer it. My biggest complaint is what I mentioned above: it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to - I might have to debug Nix instead of Node, which is not always straightforward. In my limited experience Nix got in my way more than I’d like, and in ways I didn’t expect or want to deal with, and until it’s as seamless as something like Homebrew or apt, it’ll be a hard sell.
        rgoulter 10mo ago
        > it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to Although you're right about nix's DX being quite rough, the problem isn't exactly that it "tries to be everything for package management". Consider the assumption Nix wants to make about its packages: it should be possible to package software by putting it in some arbitrary directory (i.e. not just /usr/bin), where its dependencies are also put in (or symlinked to) some arbitrary location. I think with well-written software, this should be a reasonable assumption, but you're going to run into friction with that. (Friction which will require you to have a good breadth/depth of understanding). In my experience, a lot of the complexity when dealing with Nix is with the large and organic complexity of nixpkgs. The "trying to be everything" is more incidental to the expressive package management. -- NixOS is 'just' an OS built upon the package manager; dev shells are 'just' shells which expose the build environment of a package; etc.
- c7b 10mo ago
  > 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. Couldn't pretty much all of that be addressed using containers? Keeping your base system clean does sound wonderful, but eg distrobox containers sound more approachable - you're using all the same commands that you normally would, apps are in an environment much closer to what they probably expect. You can still roll back using snapshots, which you can configure to be automatically created on system updates. If you want an atomic rollback guarantee, and a strong reminder not to mess with the base system, you can use an immutable distro (talking about Linux, not macOS here). The one big advantage that I see from nix is reproducibility. But it's not clear how desirable that is for a desktop use case. You may actually want different software on different machines. Having an overview of all the changes you made to your system sounds cool, but I'm not sure it's worth the effort that comes with nix. I'm worried that after 8 months I'll decide it's too much hassle, like many commenters seem to do, and end up switching to a simpler system with dotfiles and containers, wishing I'd done that from the start.
undeveloper 10mo ago
> 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.
nothrabannosir 10mo ago
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.
- rgoulter 10mo ago
  Right. 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.
  - fnordlord 10mo ago
    Yeah, I'm a Nix user and fan but I'm still going to be stuck fixing it when it breaks. The biggest thing that I have to remind myself is that reproducible != "just works." Once you get to what you want, you're set but until then and every change after, there's a chance you'll be in the weeds. At least from my usage, the fact that your configuration is all tied to whether the entirety of nixpkgs-unstable is working can be a real headache. Like recently when CMake was upgraded to 4.0, it took down a healthy handful of packages, which meant you couldn't update anything until things were resolved or you were really fluent in Nix hackery. (I was the former)
    - nothrabannosir 10mo ago
      I have sworn off nixpkgs-unstable for basically anything but testing. I’m now on the 6 months stable release cadence and never going back. Much much better experience. Unstable really is unstable. And that’s great! But it’s not for me.
qn9n 10mo ago
Also with migration assistant on Mac you basically do not need this in anyway shape or form.
microtonal 10mo ago
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.
- 16 10mo ago
  It sounds like you're on unstable? Things are significantly more stable if you stick to the release branches (25.05, 25.11 etc)
- yjftsjthsd-h 10mo ago
  > 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. Er, YMMV I guess? IMO if you're spending more than an hour fussing with it per 6 months, you're doing something weird
vages 10mo ago
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.

by otikik 10mo ago

loveparade 10mo ago

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.

trinix912 10mo ago
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.
- yladiz 10mo ago
  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.
  - rgoulter 10mo ago
    I think the comparison is "X-as-code", like with Terraform and other tools. If you just want a throwaway VM, it's straightforward to create one through the UI cloud console. Whereas, terraform is nevertheless still a useful tool to use to manage VMs. For stuff like installing development dependencies.. it's maybe not difficult to copy-and-paste instructions from a readme, but solutions like devcontainers or Nix's development shells can be useful even if costing more overhead.
    - yladiz 10mo ago
      Of course. I wouldn’t say that Nix is a tool without much use or merit, because setting up development environments can be a huge pain and I understand why some people would use it and prefer it. My biggest complaint is what I mentioned above: it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to - I might have to debug Nix instead of Node, which is not always straightforward. In my limited experience Nix got in my way more than I’d like, and in ways I didn’t expect or want to deal with, and until it’s as seamless as something like Homebrew or apt, it’ll be a hard sell.
      - rgoulter 10mo ago
        > it’s trying to be everything for package management, and adds a lot of complexity (and I disagree that it’s always necessary/inherent) compared to just installing a tool and sometimes upgrading it. That complexity often means I have to debug it rather than the tool that I want to Although you're right about nix's DX being quite rough, the problem isn't exactly that it "tries to be everything for package management". Consider the assumption Nix wants to make about its packages: it should be possible to package software by putting it in some arbitrary directory (i.e. not just /usr/bin), where its dependencies are also put in (or symlinked to) some arbitrary location. I think with well-written software, this should be a reasonable assumption, but you're going to run into friction with that. (Friction which will require you to have a good breadth/depth of understanding). In my experience, a lot of the complexity when dealing with Nix is with the large and organic complexity of nixpkgs. The "trying to be everything" is more incidental to the expressive package management. -- NixOS is 'just' an OS built upon the package manager; dev shells are 'just' shells which expose the build environment of a package; etc.
c7b 10mo ago
> 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. Couldn't pretty much all of that be addressed using containers? Keeping your base system clean does sound wonderful, but eg distrobox containers sound more approachable - you're using all the same commands that you normally would, apps are in an environment much closer to what they probably expect. You can still roll back using snapshots, which you can configure to be automatically created on system updates. If you want an atomic rollback guarantee, and a strong reminder not to mess with the base system, you can use an immutable distro (talking about Linux, not macOS here). The one big advantage that I see from nix is reproducibility. But it's not clear how desirable that is for a desktop use case. You may actually want different software on different machines. Having an overview of all the changes you made to your system sounds cool, but I'm not sure it's worth the effort that comes with nix. I'm worried that after 8 months I'll decide it's too much hassle, like many commenters seem to do, and end up switching to a simpler system with dotfiles and containers, wishing I'd done that from the start.

undeveloper 10mo ago

> 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.

nothrabannosir 10mo ago

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.

rgoulter 10mo ago
Right. 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.
- fnordlord 10mo ago
  Yeah, I'm a Nix user and fan but I'm still going to be stuck fixing it when it breaks. The biggest thing that I have to remind myself is that reproducible != "just works." Once you get to what you want, you're set but until then and every change after, there's a chance you'll be in the weeds. At least from my usage, the fact that your configuration is all tied to whether the entirety of nixpkgs-unstable is working can be a real headache. Like recently when CMake was upgraded to 4.0, it took down a healthy handful of packages, which meant you couldn't update anything until things were resolved or you were really fluent in Nix hackery. (I was the former)
  - nothrabannosir 10mo ago
    I have sworn off nixpkgs-unstable for basically anything but testing. I’m now on the 6 months stable release cadence and never going back. Much much better experience. Unstable really is unstable. And that’s great! But it’s not for me.

qn9n 10mo ago

Also with migration assistant on Mac you basically do not need this in anyway shape or form.

microtonal 10mo ago

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.

16 10mo ago
It sounds like you're on unstable? Things are significantly more stable if you stick to the release branches (25.05, 25.11 etc)
yjftsjthsd-h 10mo ago
> 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. Er, YMMV I guess? IMO if you're spending more than an hour fussing with it per 6 months, you're doing something weird

vages 10mo ago

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.