Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My First Impressions of Nix

mtlynch.io

Post reply on HN
Print view View original

171–180 of 354 posts

Re: My First Impressions of Nix

#171

Post by assbuttbuttass »

lolinder wrote: post #145
hamandcheese wrote: post #41

Earlier quoted context omitted.

It seems like Nixpkgs aims to minimize the number of package versions in use at one time. Not just nix, most package managers do, it seems (i.e. you wouldn't expect to find different minor versions of Nginx in Debian, would you?) So by that same logic, there is only one version of Django 4. It is definitely possible with Nix to use the precise versions of what's in your requirements.txt, but I'm not sure if the Nixpk…

Doesn't this auto-upgrade behavior punch straight through the reproducibility Nix is supposed to be giving you? It's not exactly a functional build system if the results you get depend on when you download the dependencies. (I mean, I guess you could say that time is an input to the function, but that seems to miss the point.)

You can think of the function inputs as:

1. All the package definitions in nixpkgs

2. Any external sources

When a package is updated in nixpkgs, input #1 changes.

Re: My First Impressions of Nix

#172

Post by skulk »

thumbuddy wrote: post #158
SuperSandro2000 wrote: post #150

Earlier quoted context omitted.

> Extremely complicated and hard to understand That is absolutely not true. If you start to get the hang of it and follow the way things are supposed to be done then things get easier over time. You need to invest upfront more time into your configuration but on the long run it pays off and saves you from an entire error class. > projects that use it have builds fail anyway The point of Nix/NixOS is not to have no fa…

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.

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.

Re: My First Impressions of Nix

#173

Post by justinhj »

ParetoOptimal wrote: post #149
thumbuddy wrote: post #107

Earlier quoted context omitted.

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

> In my opinion the problem it attempts to solve doesn't really exist. It does, but some people are good at numbing themselves to it. So they block losing a day or half day from lack of reproducibility out of their memory or recall it as "no big deal".

Nobody loses time on Nix issues?

Re: My First Impressions of Nix

#174

Post by jordanbeiber »

ed25519FUUU wrote: post #166
jordanbeiber wrote: post #163

Biggest drawback of ansible is that it is stateless and as such you can’t simply declare a desired system state and apply it. Nix is absolutely awesome in that regard. Possibly this is Ansibles biggest strength as well, as it feels incredibly simple to get going. Salt has a much steeper learning curve due to both weird nomenclature and the infrastructure. Nix is in many ways easy to use “on the surface” but quickly b…

Maybe I’m naive but I’ve just never found various “states” to be desired in config management. It’s always binary: either in the “right” state or a bad one!

If you have drift in actual state using Ansible you have to account for all eventualities and you simply can’t declare “make my system(s) look like this”.

I’m talking “desired state” here and how to fulfill it - not “various states to switch between”.

With nix(os) I feel you treat a machine more like an appliance!

Re: My First Impressions of Nix

#175

Post by pmarreck »

thumbuddy wrote: post #107
adamgordonbell wrote: post #92

Earlier quoted context omitted.

Explaining what Nix is seems like one of its biggest barriers to adoption. Part of the difficulty is it means different things to different people. My colleague spent a whole lot of time trying to answer this question and ended up with this: My main take away after spending some time learning about Nix is that it embraces the functional programming concept of a pure function. If I give a function a certain set of inp…

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

You basically have two choices: you can take the complexity upfront, and in a predictable fashion by learning Nix, or you can deal with the complexity after the fact when you’re dealing with dependency hell and a deadline is looming and your boss and/or client is mad.

The Nix language is basically JSON plus syntax sugar plus pure functions. A Nix derivation can be thought of as a super-powered lockfile that includes not just the versions of the dependencies, but also the build instructions and the environment in which to build them.

The argument for Nix is basically the same argument as the one for writing pure functions as much as possible, or not doing so. Any amount of experience doing the former will demonstrate that it is superior.

Now, Nix may be complex, and some of that may be reducible, but the fundamental idea of treating a build like a pure function is NOT reducible, and is well worth the effort of learning, because it will apply to ANY future pure build and dependency management tool

Re: My First Impressions of Nix

#176

Post by lolinder »

superkuh wrote: post #148
p-e-w wrote: post #13

I've occasionally encountered projects using Nix, and I've casually browsed the Nix and NixOS websites, but I still don't have a clear idea of what Nix is. Is it a package manager? A build system? An operating system? A container platform? A sandbox? An automation tool? Which widely used, existing software tools is it analogous to?

Nix is a distro that admits defeat against dependency management and entirely gives up on the idea of having system libraries. Instead every application you want to run has to have all of it's dependencies explicitly stated and provided custom in nix style configs for each program. Usually this means someone else has done all this packaging work for you. They hate it when people call it containerization but it's effe…

I think you're thinking of NixOS, which is a distro based on Nix. Nix itself is not a distro.

Ironically, this further emphasizes how confusing the project is (projects are?).

Re: My First Impressions of Nix

#177

Post by lolinder »

assbuttbuttass wrote: post #171
lolinder wrote: post #145

Earlier quoted context omitted.

Doesn't this auto-upgrade behavior punch straight through the reproducibility Nix is supposed to be giving you? It's not exactly a functional build system if the results you get depend on when you download the dependencies. (I mean, I guess you could say that time is an input to the function, but that seems to miss the point.)

You can think of the function inputs as: 1. All the package definitions in nixpkgs 2. Any external sources When a package is updated in nixpkgs, input #1 changes.

I mean, I get that, but that means that the reproducibility of my build depends on the whims of the nixpkgs maintainers, it's not a property guaranteed by the package manager.

Re: My First Impressions of Nix

#178

Post by __MatrixMan__ »

thumbuddy wrote: post #158
SuperSandro2000 wrote: post #150

Earlier quoted context omitted.

> Extremely complicated and hard to understand That is absolutely not true. If you start to get the hang of it and follow the way things are supposed to be done then things get easier over time. You need to invest upfront more time into your configuration but on the long run it pays off and saves you from an entire error class. > projects that use it have builds fail anyway The point of Nix/NixOS is not to have no fa…

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.

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.

Re: My First Impressions of Nix

#179

Post by _7tgr »

superkuh wrote: post #148
p-e-w wrote: post #13

I've occasionally encountered projects using Nix, and I've casually browsed the Nix and NixOS websites, but I still don't have a clear idea of what Nix is. Is it a package manager? A build system? An operating system? A container platform? A sandbox? An automation tool? Which widely used, existing software tools is it analogous to?

Nix is a distro that admits defeat against dependency management and entirely gives up on the idea of having system libraries. Instead every application you want to run has to have all of it's dependencies explicitly stated and provided custom in nix style configs for each program. Usually this means someone else has done all this packaging work for you. They hate it when people call it containerization but it's effe…

Well, sure, but setting up the build environment is pretty easy! You just specify the libraries as you normally would, and it works. The only difference is that those libraries are only available to that package, and not globally. The function `stdenv.mkDerivation` will actually build a standard ./configure && make style C project for you if you provide it some package source, you just have to copy out the build artifacts (with something like (cp project bin/project) and specify a list of libraries needed at build/runtime.

Agree that the documentation for all of this could be a lot better and more discoverable. It's good once you get over the initial hump though.

Re: My First Impressions of Nix

#180

Post by duped »

superkuh wrote: post #148
p-e-w wrote: post #13

I've occasionally encountered projects using Nix, and I've casually browsed the Nix and NixOS websites, but I still don't have a clear idea of what Nix is. Is it a package manager? A build system? An operating system? A container platform? A sandbox? An automation tool? Which widely used, existing software tools is it analogous to?

Nix is a distro that admits defeat against dependency management and entirely gives up on the idea of having system libraries. Instead every application you want to run has to have all of it's dependencies explicitly stated and provided custom in nix style configs for each program. Usually this means someone else has done all this packaging work for you. They hate it when people call it containerization but it's effe…

> They hate it when people call it containerization but it's effectively taking containerization to the extreme for every single bit of software on your system with no ability to not use containers.

It's not containerization - containerization means something very specific (user namespaces + chroot). It may attack some of the same problems, but it is not a container.

The sandbox that nix builds run within is more or less a container, however.

Post reply on HN