Live data from Hacker News

My First Impressions of Nix

mtlynch.io

111–120 of 354 posts

Re: My First Impressions of Nix

#111

> Using VS Code Remote SSH on NixOS systems This is the main of issue with Nix and other niche distributions: they are new operating systems, with their set of file layouts, package managers, and even syscall variations. Linux ecosystem is awfully fragmented. If you ever want to use any software outside of your not-very-well-walled-garden provided by distribution authors, you have to hope your operating system (that…

I don't see how NixOS doesn't provide 2. It's extremely easy to apply patches.

Depending on what you are patching, it will invalidate a great part of the cache, and you will be looking at very long build times for everything in your system.

Re: My First Impressions of Nix

#112

Earlier quoted context omitted.

I've used Nix for 5 years now and use it heavily in production, and in my opinion, just do what works for you. If you try and use Nix 100% "correctly" then you'll end up like the countless other people who tried Nix and failed. Especially for toying around in dev environments, be pragmatic and take advantage of its amazing strengths, but if distrobox lets you enjoy using NixOS and speed up your workflow, so be it. He…

Or you could... You know... Not use Nix?

So give up all my baseline hardened VM configurations and go back to patchy Ansible scripts that leave the OS in a different state every time? No thanks

Re: My First Impressions of Nix

#113

> Using VS Code Remote SSH on NixOS systems This is the main of issue with Nix and other niche distributions: they are new operating systems, with their set of file layouts, package managers, and even syscall variations. Linux ecosystem is awfully fragmented. If you ever want to use any software outside of your not-very-well-walled-garden provided by distribution authors, you have to hope your operating system (that…

I don't see how NixOS doesn't provide 2. It's extremely easy to apply patches.

I guess it should rather say that NixOS provides 1 and 2, since I don't see how it would be ABI compatible to a major distribution.

Re: My First Impressions of Nix

#114
post #113

Earlier quoted context omitted.

I don't see how NixOS doesn't provide 2. It's extremely easy to apply patches.

I guess it should rather say that NixOS provides 1 and 2, since I don't see how it would be ABI compatible to a major distribution.

With FHS I'd say it does 3 also.

Re: My First Impressions of Nix

#115
post #113

Earlier quoted context omitted.

I guess it should rather say that NixOS provides 1 and 2, since I don't see how it would be ABI compatible to a major distribution.

With FHS I'd say it does 3 also.

Ah, fair enough, though it feels a bit like stretching the definition.

Re: My First Impressions of Nix

#116

> Nix, on the other hand, does have a concept of state. If you make a one-line change to a 200-line Nix configuration, it doesn’t have to re-do all the work from the other 199 lines. It can evaluate the state of the system against the configuration file and recognize that it just has to apply the one-line change. And that change usually happens in a few seconds. The author seems to have some misguided ideas about Nix…

Author here.

Thanks for the clarification! I'm still new to Nix, so I'm trying to share useful things I'm learning without overstepping my expertise and saying wrong things.

My mental model of Nix was that if I'm in system state A, which is the result of performing task X + Y, and I want to get to system state B, which is the result of task X + Y + Z, then Nix would recognize that it's already in state A, so it only has to perform task Z to get to state B.

It sounds like what you're saying is that Nix's actual behavior is that if I'm in state A and tell Nix to bring me to state B, then Nix still performs tasks X and Y again, but the results are cached, so tasks X and Y feel as fast as a no-op, and the only task I perceive as taking time is task Z.

Is that right?

Re: My First Impressions of Nix

#117

Earlier quoted context omitted.

Did you read the entire comment? The core idea of functional programming is pure functions (given the same outputs, the output is always the same). Nix applies that to building systems.

Pure functions are just a concept that is used in FP world Yet, pure functions can "stand alone". You do not need FP to use pure functions. They are independent from FP. You can be OOP maniac and still use them. So unless you want to sound fancy and trendy then why call Nix functional instead of side-effects free?

How is "side-effects free" less fancy and trendy than functional?

Re: My First Impressions of Nix

#118

Earlier quoted context omitted.

Did you read the entire comment? The core idea of functional programming is pure functions (given the same outputs, the output is always the same). Nix applies that to building systems.

Pure functions are just a concept that is used in FP world Yet, pure functions can "stand alone". You do not need FP to use pure functions. They are independent from FP. You can be OOP maniac and still use them. So unless you want to sound fancy and trendy then why call Nix functional instead of side-effects free?

Because it is basically a dynamically typed Haskell? It also does currying.

Like, there is no one definition of FP, but Nix is definitely an FP language as well as the whole idea behind it.

Re: My First Impressions of Nix

#119

Earlier quoted context omitted.

You can package simple python projects, but as soon as there are too many huge deoendecies that use CPython and whatnot, it becomes impossible to generate the nix derivation. I just use imperative python-venv + pip install on those.

Wasn't Nix supposed to solve these problems?

It does. Nix can package everything properly. What is depending on the language ecosystem in question is whether this packaging can be more automized or not.

Python is not trivially automatized with Nix.

Re: My First Impressions of Nix

#120

Earlier quoted context omitted.

I don't see how NixOS doesn't provide 2. It's extremely easy to apply patches.

Depending on what you are patching, it will invalidate a great part of the cache, and you will be looking at very long build times for everything in your system.

If that dependency is deep in your dep tree and is statically linked somewhere than there is no way preventing that.

If it’s only dynamic linking than yeah, it might happen that you need a huge recompile (but that is not that big of a problem nowadays in my experience - gentoo used to compile way longer in my subjective experience for example). Also note: nix will soon get content-based hashing which may solve this problem.

Post reply on HN