Nix: Taming Unix with Functional Programming • Hacker News Board

Re: Nix: Taming Unix with Functional Programming

#71

Post by otabdeveloper4 » Fri, Aug 05, 2022, 5:22 PM UTC

oneplane wrote: post #69

fesc wrote: post #56

Man, there’s a lot of negative comments here. Just to add a different experience: my company loves Nix, it makes it really easy to integrate new tools into the dev/build environment without needing to document which packages, configuration, … a developer needs to apply to their machine manually. There’s nothing like it, really.

There are many things like it. For example, managed operating environments where the user doesn't need to do anything (and actually can't do anything). Or disposable environments like VMs and containers. Sure, it's not the same as massaging a special pet operating system over and over, but most people that need to produce software hopped off of that bandwagon years ago. I get that companies that do functional program…

Nix is not an operating system. It can be used to build operating systems easily, though.

Also, there isn't anything "functional" about Nix. It's a nice sales pitch, but underneath it's just a thin layer over bash scripts and environment variables.

Re: Nix: Taming Unix with Functional Programming

#72

Post by jnxx » Fri, Aug 05, 2022, 5:41 PM UTC

infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

> This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does

Does Arch not do that?

Re: Nix: Taming Unix with Functional Programming

#73

Post by jnxx » Fri, Aug 05, 2022, 5:43 PM UTC

pxc wrote: post #65

infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

Yeah. This is covering stuff you know if you've read that thread, but: Putting all Python libs into a single channel is something Nixpkgs does because Python can't handle different versions of the same library in a single process. The Python libs that are used in actual applications in NixOS, then, need to be compatible or they might cause weird issues when a new or existing package tries to leverage them at the same…

> The Python community faces some really tough institutional/governance/adoption problems

The Linux kernel people could have the same problems... it is genius how they have solved them, by developing git but also by establishing processes that scale.

Re: Nix: Taming Unix with Functional Programming

#74

Post by KingMachiavelli » Fri, Aug 05, 2022, 5:49 PM UTC

agentultra wrote: post #34

Nix seems great for build servers. This is a great introduction to the motivations behind it. I'm not sold on using it for managing developer environments (another use case it is often used for). It "solves" the problem that developers might be using different versions of libraries or compilers on their machines... but it comes at the cost of having to learn a whole new programming language, a configuration language,…

In my experience Nix works pretty great for developer environments when you don't previously have anything more than manually configured dev servers. (In general Nix is much easier to buy into if you don't already extensively use Docker, k8s, etc.)

For smaller teams with less experienced developers any tool is going to have a fairly high learning curve. Instead of having everyone learn Nix or Docker, it's very easier to have a few, more Linux experienced devs configure servers and devshells using Nix while providing simple TUI for developers to access various tools.

There are some headaches, if you want to use a full NixOS environment then there are some complications with tools like VSCode and NodeJS that download dynamically linked binaries but its terrible difficult to workaround.

Re: Nix: Taming Unix with Functional Programming

#75

Post by euroclydon » Fri, Aug 05, 2022, 5:51 PM UTC

I built my router and NAS from NixOS. It was a mostly pleasant experience. Being able to sit in an IDE on my laptop, and build up a server, incrementally pushing changes to it, with rollback if necessary, was great, and I wouldn't want to go back to anything else.

I wrote about the router here. It's pretty heavy on router stuff, and my own thoughts though...

https://www.jjpdev.com/posts/home-router-nixos/

Re: Nix: Taming Unix with Functional Programming

#76

Post by jnxx » Fri, Aug 05, 2022, 5:54 PM UTC

infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

> As an observer it looks like Python's package ecosystem in particular is a giant mess.

Most people would say it is. The better question is how to avoid such a mess.

My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. And yeah, that has also become a cultural issue with Python, as the Python2/3 breakage shows.

So, could one sum it up in that Nix magnifies unsolved compatibility issues in packaging systems? Because if there were a single core Python distribution, like say, Anaconda, but nothing else, these issues would not exist. Of course, people can avoid the issues if they only use a handful of packages. But putting all into a single channel makes the problem much more acute.

Re: Nix: Taming Unix with Functional Programming

#77

Post by infogulch » Fri, Aug 05, 2022, 5:55 PM UTC

jnxx wrote: post #72

infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

> This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does Does Arch not do that?

Maybe it would be more correct to say that "Nix integrates all package updates into one channel which is unique to system integrators (like Nix and Arch) but an uncommon workflow for regular application developers".

Re: Nix: Taming Unix with Functional Programming

#78

Post by infogulch » Fri, Aug 05, 2022, 5:57 PM UTC

jnxx wrote: post #76

infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

> As an observer it looks like Python's package ecosystem in particular is a giant mess. Most people would say it is. The better question is how to avoid such a mess. My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. And yeah, that has also become a cultural issue with Python, as the Python2/3 breakage shows. So, could one sum it up in th…

> Nix magnifies unsolved compatibility issues in packaging systems ... putting all into a single channel makes the problem much more acute

Well said.

Re: Nix: Taming Unix with Functional Programming

#79

Post by jnxx » Fri, Aug 05, 2022, 5:57 PM UTC

ryukafalz wrote: post #36

jnxx wrote: post #15

Earlier quoted context omitted.

I have tried Guix (as a package manager), and it seems much better documented. I also really like the fact that Guix uses a well-established, minimalistic, well-implemented, functional-preferred configuration language, which is Guile, the GNU implementation of Scheme, which is very much tailored to be extended with and embedded in other software, for example written in C. In part, my love comes from having had to use…

I much prefer Guix UI-wise but it has some downsides: — I’ve had more jank on Guix System as a desktop OS than on NixOS. Specifically some dbus-related stuff like notifications and appindicators (when running sway + waybar) has been very unreliable for me under Guix in ways that it hasn’t been on any other distro I’ve tried including NixOS. Still haven’t figured out why. - Guix is slow compared to Nix. This is especi…

> - Guix is slow compared to Nix. This is especially noticeable on older/weaker hardware.

Yeah, I have noted it is not the fastest snail on the lawn. On the other hand, I have seen so much time wasted on integration and reproducibility issues, that I'd be happy to run one day a week nothing else than a Guix install and not have any of these issues.

Re: Nix: Taming Unix with Functional Programming

#80

Post by soraminazuki » Fri, Aug 05, 2022, 6:04 PM UTC

enoyls wrote: post #70

rgoulter wrote: post #12

Earlier quoted context omitted.

> For x86, the package availability is almost unparalleled. https://repology.org/repositories/statistics/total In terms of total number of packages, nixpkgs unstable is at 72k, while AUR is at 68k. I'd bet there are many caveats, though.

I'm not sure what point you're trying to make. AUR is a supplementary set of packages, and it looks like you're comparing it to the total number that Nix supports. Wouldn't a more fair comparison would be official Arch packages + AUR to nixpkgs?

No, because that would be comparing the number of official packages + third party packages with duplicates in Arch against the number of official packages in Nixpkgs. That's as fair as comparing the number of official Nixpkgs packages + every unofficial Nix package on GitHub against the number of official Arch packages.