Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

After my personal 2-year experiment with NixOS, I'd avoid anything Nix like the plague, and would be looking for a new job if anyone instituted a Nix-only policy.

It's not the learning new things that's a problem, but rather the fact that every little issue turns into a 2-day marathon that's eventually solved with a 1-line fix. And that's because the feedback loop and general UX is just awful - I really started to feel like I needed a sacrificial chicken.

Docker may be a dumpster fire, but at least it's generally easy to see what you did wrong and fix it.



Literally every Docker image you've ever downloaded comes from a build that only worked (essentially) "by accident."

If Docker builds were as deterministic as Nix, then all that would need to be distributed would be Dockerfiles and perhaps a cache of base images somewhere.

Looking at a build as a pure function where each dependency (including any compiler(s), plus the environment), are "input arguments" to it, was a revelation (since I already realized the advantages of pure functions while working in functional languages).

Running a Dockerfile and hoping to get a working image out of it is like running a function which checks the time when it runs and errors when the seconds end in 0 due to a bug.

> every little issue turns into a 2-day marathon that's eventually solved with a 1-line fix

There is spotty education in the space. Did you ever take this (very cool) Nix tutorial? Not actually understanding Nix is going to make any troubleshooting of Nix much harder. https://nixcloud.io/tour/

> I really started to feel like I needed a sacrificial chicken.

Have you looked at Guix? A lot of people think it's "Nix without the warts." Plus it uses a Lisp, which some people prefer, or can at least grok better than the Nix language. https://guix.gnu.org/


I watched all the videos, read all the tutorials (including the "super easy" ones). I understand the Nix language, but the actual infrastructure is just so damn convoluted and fragile, the error feedback mechanisms are worse than useless, and the documentation assumes that you already know everything inside and out. It reminds me of the bad old days of the neckbeard gatekeepers.

I'll take a look at guix, though...


"Working by accident" is still "working" though, so from the standpoint of the person using it, the reason doesn't matter. I'd also argue that the main point made above about docker wasn't that it's reliable, but that it gives developers more feedback when trying to work with it. For people who's goal isn't just to consume builds but write their own, existing Nix builds being deterministic does nothing to help them if trying to modify or borrow parts of them leads to issues they can't easily fix.

I think Nix fits a pattern that's happened in plenty of other domains where the technology that focused on doing things "right" failed to win out against a competitor doing things "wrong" but optimizing for a lower barrier of entry. The logic that a perfect solution is worth an up-front cost is compelling, since having an imperfect solution has a long-term cost that never goes away, but this misses the fact that pushing the cost until later has value of its own; making things easier today at the cost of tomorrow buys time to improve things before the cost is incurred.

At the risk of a convoluted metaphor, imagine that someone moves into a new house and calls two plumbers asks them to hook up the water in their bathroom. The first plumber says that they can get it done so the bathroom can be used today, but they'll need to come by again in a week or two since they might need to make additional adjustments. The second plumber says they've come to with a way to make sure that they never need to come back to make adjustments, but it will take them a full week to finish setting it up before anyone can use it.

For most people, it doesn't matter if the second plumber's solution will be better next week if they need to use the bathroom today, as long as the first plumber's solution can last long enough before it needs to be fixed.


> ...but at least it's generally easy to see what you did wrong and fix it.

You're not actually "fixing" anything, you're just passing the ball of shit down the responsibility chain to the ops/infra team.

Which is fine if you work in a large corporation where this is a valid strategy.

Unfortunately though the software supply chain problem is a) very difficult and b) unavoidable.

Nix is the best (or maybe only) attempt to solve this problem with programmatic (vs organizational) tooling.


I've got nothing against the fundamental concepts that Nix strives for. In fact, that's what triggered my 2 year journey with it. I just hate the implementation with a passion. The overall result is worse than before.


There is no possible way to solve anything in this problem space without triggering developer PTSD. The implementation is not at fault.

(See npm or the clusterfuck of Python packaging for proof.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: