5 ms·

If you are only using nix as an imperative package manager just like homebrew, there is little advantage. One area where nix shines is that you can write nix c

If you are only using nix as an imperative package manager just like homebrew, there is little advantage. One area where nix shines is that you can write nix code to build a reproducible dev environment for your project. You can think of it kind of like if you could use a Brewfile to build a virtualenv that doesn't touch your system at all. I like this a lot because it makes dusting off old projects way easier. I don't have to worry about the state of my system, or reverting to an old version of ruby, etc. to get the old project running again. Nix is also much more powerful than a Brewfile. You can override the versions of dependencies or even package your own custom dependencies and use those in exactly the same way. The learning curve is steep, but once you learn you have an incredible amount of flexibility and power all built on a robust foundation.

nvy 3y ago
> I don't have to worry about the state of my system, or reverting to an old version of ruby, etc. to get the old project running again. But wouldn't you want to update your project to a new(er) version of Ruby in that hypothetical? There have probably been security updates along the way.
- pxc 3y ago
  > But wouldn't you want to update your project to a new(er) version of Ruby in that hypothetical? Perhaps because it's in maintenance mode and what you really need is just to be able to run it to compare its behavior with that of its replacement, or because you want to perform the upgrade by replacing code that relies on deprecated APIs in an incremental way, in a copy of the codebase that still runs and passes tests at each step along the way. Or maybe you're a scientist and you want to run the original code because you want your tests to have the exact same performance and other characteristics as the code used in the original paper, so you want to avoid compiler/interpreter optimizations that have come out in the meantime.
  - nvy 3y ago
    Those all sound like legitimate but very niche use cases. I don't see the mainstream appeal of Nix.
    - oasisaimlessly 3y ago
      If those sound like niches, it really sounds like you've never worked on a project spanning more than a few years. Maintenance isn't 'hot', but it's something that keeps a lot of people employed. I deal with all those use cases on a day-to-day basis and Nix is a godsend.
- xp84 3y ago
  Having developed on that platform for a long time, I will say that It Depends. Clearly you shouldn't dust off a Ruby 1.8.7 app and deploy it to prod, but what would be the harm in using a script you wrote in 2012, say, to batch process a CSV to JSON? In fact, the project you're dusting off might just be an old revision of your current app that you already ported (over the years) to current standards, but you thought you wouldn't need that script so you deleted it 7 years ago rather than keep it up to date. if you could check out the old tag and run the script intact, that would be ideal.
- hamandcheese 3y ago
  Yes, I probably would want to upgrade. But it's far easier to start from a working state and change one thing at a time. Nix gives you that control.

nvy 3y ago

> I don't have to worry about the state of my system, or reverting to an old version of ruby, etc. to get the old project running again. But wouldn't you want to update your project to a new(er) version of Ruby in that hypothetical? There have probably been security updates along the way.

pxc 3y ago
> But wouldn't you want to update your project to a new(er) version of Ruby in that hypothetical? Perhaps because it's in maintenance mode and what you really need is just to be able to run it to compare its behavior with that of its replacement, or because you want to perform the upgrade by replacing code that relies on deprecated APIs in an incremental way, in a copy of the codebase that still runs and passes tests at each step along the way. Or maybe you're a scientist and you want to run the original code because you want your tests to have the exact same performance and other characteristics as the code used in the original paper, so you want to avoid compiler/interpreter optimizations that have come out in the meantime.
- nvy 3y ago
  Those all sound like legitimate but very niche use cases. I don't see the mainstream appeal of Nix.
  - oasisaimlessly 3y ago
    If those sound like niches, it really sounds like you've never worked on a project spanning more than a few years. Maintenance isn't 'hot', but it's something that keeps a lot of people employed. I deal with all those use cases on a day-to-day basis and Nix is a godsend.
xp84 3y ago
Having developed on that platform for a long time, I will say that It Depends. Clearly you shouldn't dust off a Ruby 1.8.7 app and deploy it to prod, but what would be the harm in using a script you wrote in 2012, say, to batch process a CSV to JSON? In fact, the project you're dusting off might just be an old revision of your current app that you already ported (over the years) to current standards, but you thought you wouldn't need that script so you deleted it 7 years ago rather than keep it up to date. if you could check out the old tag and run the script intact, that would be ideal.
hamandcheese 3y ago
Yes, I probably would want to upgrade. But it's far easier to start from a working state and change one thing at a time. Nix gives you that control.