Comment by maartenh | Hacker News Reader

Comment by maartenh | Hacker News Reader

I love Nix. I use it on my homesteaders, and private laptop.

I have seen how it works great in a team, if all are onboard.

No place I've worked at was interested in the advantages of Nix though.

I wonder if switching to something less recognizable to a functional programming language might help adoption.

The approach Starlark (the DSL for Bazel) has taken, is have mutable datastructures, but freeze them after they are evaluated. This seems a lot more explainable and debuggable for the average programmer.

Infinite recursion errors are not fun to debug in Nixlang.

At my current job, NX is used to be a kind of Nix, but it does not seem to try to solve the entire problem space. Just to solve the additional complexity that introducing a monorepo in regards to tracking build dependencies.

It seems to me that how awesome Nix is from a tech perspective, it doesn't make delivering actual software any easier without team buy-in and effort in integrating in their delivery pipelines.

The problems with Nix have nothing to do with FP per se. The problems with Nix start long before you get to any programming. Take the home page. The first two sentences on the hero image:

1. "Reproducible builds and deployments." OK, this is exactly Docket etc. claim. No differentiation here.

2. "Nix is a tool that takes a unique approach to package management and system configuration." Uh, why should I care? What problem is this solving? What's the benefit to me?

And it continues throughout Nix. E.g. advice in this thread that the only sane way to use Nix is with Flakes, which are some semi-documented experimental feature of Nix. It's just terrible user experience right from the start. Just read the thread.

I agree that the FP part is not the only issue. It's that the community feels a bit more academic/I'll fix this for myself in the way that works best for me.

You can indeed achieve some reproducibility with Docker. It's tricky though, as you'd have to pin exact package versions of software. If you'd `FROM ubuntu:$VERION`, and would run an `apt-get update`, you're not guaranteed to get the same software.

Nix is like ZFS, as that it breaks the wall between two previously distinct area's. Those being building software, and installing/configuration software on your OS. It's quite different from the snapshot-everything methodology that Docker uses. Yeah, one can split in multi-stage images etc, but than you'll be keeping track of which dependencies need to be moved between the stages yourself, in a manner that cannot be abstracted away, so you're doomed to repeat the same patterns over and over again.

People also state that LVM + ext3 is more than sufficient compared to the complexity of ZFS. They miss out on the fact on how much more fine grained solutions are possible with ZFS.

I've used niv [0] before flakes arrived, and am actually still using that instead of flakes. The experimental nature of them has scared me away from them, as I'm not daily involved in this ecosystem at the moment.

[0] https://github.com/nmattia/niv#niv

Not to even mention that you just went into nixos.org and now it's talking about Nix(not NixOS).

> 1. Reproducible builds and deployments.

Docker doesn't give you reproducible, it gives you repeatable 90% of the time.

> 2. "Nix is a tool that takes a unique approach to package management and system configuration."

> Uh, why should I care? What problem is this solving? What's the benefit to me?

Because #2 enables Nix to actually deliver 100% reproducibile builds and deployments.

Complete opposite experience. Even with engineers who knew their stuff. It's been more of a burden in my opinion then a tool. Just use GitHub actions and docker.

Reply on news.ycombinator.com