5 ms·

I've never seen it actually pay off in industry. I've seen it be used as good job security while other devs just wrote docker files and got things done.

skulk 3y ago
Then you're not paying enough attention. There are plenty of companies using nix to distribute a reproducible environment (if you don't believe me, why not go search GitHub for "flake.nix" and see how many "industry" repos you find). I think it would be more productive for you to sit down and give it a fair chance than posting little rebukes all over this thread.
- thumbuddy 3y ago
  I gave it a fair chance and it was a deciding factor in why I left a company believe it or not. Only one person could maintain and fix deployments. Not from lack of trying from seasoned experts and no new comers. It was the worst user experience I have probably ever encountered. Meanwhile I was able to pick up terraform and docker in a matter of days...
__MatrixMan__ 3y ago
As the only guy maintaining the flake.nix in my team's repo, I don't think it's really contributing to my job security. I'm just happy that they don't mind the extra files and commits here and there because I value the ability to contribute from different devices without worrying about which versions of what are installed. Maybe it'll be job security if people start agreeing that downloading binary tools in in CI without a hash check is unacceptable attack surface, but until then it's just this weird thing I'm doing on the side. I do catch a lot of bugs where people are relying on dependencies that they happen to have installed but have not declared. It's the kind of thing that prevents newcomers from being successful out of the gate, or makes taking a local process and putting it in CI difficult, but fixing those is not exactly high visibility.
SuperSandro2000 3y ago
If you have something easy to deploy like a go binary you can just write a dockerfile but for big python projects that start to compile dependencies that is quickly no longer true. The dockerfile likely is also not matching the software you run and test on your local machine, so sometimes debugging is not as easy. Ofcourse you can debug inside the container but then you are missing all your tooling and need to bring that with you. And rebuilding a dockerfile is often not reproducible, so if you want the container back from 1 year ago and you no longer have the artifact you are probably out of luck. With nix you can easily open a shell with the packages used in the docker image or go back in time and reproduce that image from a year ago with the flake.lock from a year ago. Also applying patches to dependencies used in dockerfiles is not dead easy as with nix.
- thumbuddy 3y ago
  Most people would opt to not apply patches to their dependencies in my experience. Seems kinda sketchy if that's something you have to do on a regular basis. I'd chalk that up as a possibly serious business concern depending on the magnitude of the fixes, the importance of the dependency, and the frequency.
kaba0 3y ago
I have written software that would have been 100% not package-able any other way. Also, let’s not lie to ourselves, there are plenty of ridiculous contraptions out there, like docker-images used for ML that take up some insane space, and are updated each day. Packaging is a hard problem, and there is finally a tool that can actually solve it.
ElectricalUnion 3y ago
In my experience those "others" that "just wrote docker files" are exatly the ones that don't know how to build the system in a reproducible manner if their ci environment gets reset for some reason as they find out that stuff that was "supposed to be there, pinned and configured" wasn't.
- thumbuddy 3y ago
  In my experience the months required to get a handle on Nix is not worth the benefit(which is shakey in my opinion) compared to competing technologies. We don't have to agree, but that's my take...
  - ParetoOptimal 3y ago
    You might want to look at things like: https://devenv.sh/ https://devenv.sh/ https://www.jetpack.io/devbox/ https://www.jetpack.io/devbox/

skulk 3y ago

Then you're not paying enough attention. There are plenty of companies using nix to distribute a reproducible environment (if you don't believe me, why not go search GitHub for "flake.nix" and see how many "industry" repos you find). I think it would be more productive for you to sit down and give it a fair chance than posting little rebukes all over this thread.

thumbuddy 3y ago
I gave it a fair chance and it was a deciding factor in why I left a company believe it or not. Only one person could maintain and fix deployments. Not from lack of trying from seasoned experts and no new comers. It was the worst user experience I have probably ever encountered. Meanwhile I was able to pick up terraform and docker in a matter of days...

__MatrixMan__ 3y ago

As the only guy maintaining the flake.nix in my team's repo, I don't think it's really contributing to my job security. I'm just happy that they don't mind the extra files and commits here and there because I value the ability to contribute from different devices without worrying about which versions of what are installed. Maybe it'll be job security if people start agreeing that downloading binary tools in in CI without a hash check is unacceptable attack surface, but until then it's just this weird thing I'm doing on the side. I do catch a lot of bugs where people are relying on dependencies that they happen to have installed but have not declared. It's the kind of thing that prevents newcomers from being successful out of the gate, or makes taking a local process and putting it in CI difficult, but fixing those is not exactly high visibility.

SuperSandro2000 3y ago

If you have something easy to deploy like a go binary you can just write a dockerfile but for big python projects that start to compile dependencies that is quickly no longer true. The dockerfile likely is also not matching the software you run and test on your local machine, so sometimes debugging is not as easy. Ofcourse you can debug inside the container but then you are missing all your tooling and need to bring that with you. And rebuilding a dockerfile is often not reproducible, so if you want the container back from 1 year ago and you no longer have the artifact you are probably out of luck. With nix you can easily open a shell with the packages used in the docker image or go back in time and reproduce that image from a year ago with the flake.lock from a year ago. Also applying patches to dependencies used in dockerfiles is not dead easy as with nix.

thumbuddy 3y ago
Most people would opt to not apply patches to their dependencies in my experience. Seems kinda sketchy if that's something you have to do on a regular basis. I'd chalk that up as a possibly serious business concern depending on the magnitude of the fixes, the importance of the dependency, and the frequency.

kaba0 3y ago

I have written software that would have been 100% not package-able any other way. Also, let’s not lie to ourselves, there are plenty of ridiculous contraptions out there, like docker-images used for ML that take up some insane space, and are updated each day. Packaging is a hard problem, and there is finally a tool that can actually solve it.

ElectricalUnion 3y ago

In my experience those "others" that "just wrote docker files" are exatly the ones that don't know how to build the system in a reproducible manner if their ci environment gets reset for some reason as they find out that stuff that was "supposed to be there, pinned and configured" wasn't.

thumbuddy 3y ago
In my experience the months required to get a handle on Nix is not worth the benefit(which is shakey in my opinion) compared to competing technologies. We don't have to agree, but that's my take...
- ParetoOptimal 3y ago
  You might want to look at things like: https://devenv.sh/ https://devenv.sh/ https://www.jetpack.io/devbox/ https://www.jetpack.io/devbox/