Comment by unshavedyak | Hacker News Reader

Comment by unshavedyak | Hacker News Reader

Parent Full thread

My problem with those abstractions is:

1. That the error messages for them i find to be awful. They really need to take inspiration from Rust to help users know exactly where the API error is happening relative to your code. I've spent quite a lot of time toggling things on and off to try and find which part of code, or which package, is causing a specific failure.

2. I've not found the APIs that the abstractions provide to be stable in the same way my Rust crates/etc are. Something can randomly break between updates and i'm not sure what caused it. Takes me quite a while of digging through source to find the root cause, and digging through Nix source i find extra painful.

All around i hate this side of Nix. A lot. However it's enough of "another level" that i stay with it and don't switch away.. I use it for my Linux machines and my Mac laptop. It makes so many things so easy, the majority of the time.. but when something goes wrong.. it's super painful.

As someone who up until recently would have agreed with you, both of these are fundamentally familiarity issues. Nix's error messages really aren't that bad, but chances are there's exactly one line out of 200 that tells you what's wrong. Learning to read stack traces for a new language is part of learning that language.

I've not had issues with Nix APIs, at least not Nixpkgs or the language builtins. When something does break for me, it's usually some random JavaScript package that had some external dependency change. Nixpkgs is pretty well organized and I find navigating it not that hard once you read the packaging guidelines. find / fzf / ripgep / etc. are all great at this, as file and folder names are critical to the organization of nixpkgs.

The big turning point for me was trying to build and package a non-trivial application and build a NixOS module for it.

Package errors aren't that bad, but NixOS config errors are a nightmare because they are often a value that was computed from a value that was computed from what you wrote triggering a missing field, class mismatch, or infinite recursion in very generic framework code.

Agreed on 1, thats part of the cost you pay when choosing Nix.

Disagree somewhat on 2. Yes, there are frequently small breaking changes, but the massive upside of nix is I can either just rollback or pin a specific package at a specific version and move on.

Reply on news.ycombinator.com