lad

I think, it’s based on an old flake-compat package or something. It’s not inherently bad, but it displays what I dislike the most about Nix design, it’s very opaque and magical until you go out of your way to understand it.

The globals are another example of this, I know I can do with something; [ other ] but I am never sure if other comes from something or not. And if it’s a package parameter, the values also come seemingly out of nowhere.

Sometimes it’s also the updates, rolling back a failed update is much simpler with Nix even if it took some elaborate set-up. This might be not wildly useful but it happens more often than spinning up a new machine entirely

Personally I use flakes.

On the work we use an abomination that creates flake.lock but then parses it and uses to pin versions, it took me a while to realise this is why setting a flake input to something local never seemed to have any effect, for instance

Community publishing the configs sometimes confuses even more, because everyone does the same things differently, and some are deprecated, and some are experimental, and I was lost way more times than once while trying to make sense of it.

I like Nix, and I use it on my Mac and in our production for cross-compiling a service, but man is it a pain to fix issues. That is beside the point that for some reason Nix behaves a bit different on my machine and on co-workers’, and the only thing I wanted from it is to be absolutely reproducible