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

Cool.

After using Nix for a while I got pretty fed up with the (subjective) unintuitiveness of the language†. It wasn't even that I thought it was a bad language, I just couldn't het it to click (and doubly so after the advent of flakes).

All the same it seems to me like if you grok it it's a great fit for constructing recipes for building things reliably that are part of huge dependency trees, and so it's natural that it would be a good website generator too.

† Luckily others shared this issue, and the result was Guix which solves that problem while introducing its own.





It's a pretty special language, lazy evaluation and very basic types. However after spending the time to learn it to an intermediate level I think it's pretty great.

Flakes are not great however, they're what happens when you "overdo it", sadly the momentum is behind flakes because some UX/DX improvements came along with them (lockfile in repo).

I think the stdenv being built on bash is worse than Nix language.

Module system errors can be very hard to troubleshoot because of lazy eval, sadly I can't see a reasonable solution without worse tradeoffs :(


The flakes were the main UX/DX improvement for me. Before them I honestly could not do anything. The learning curve was so incredibly steep it almost felt like the people behind Nix were being malicious or intentionally gatekeeping. You finally stumble onto something you can at least partly understand, but then the powers that be throw two last obstacles at you like,

First, flakes are "experimental", so you have to enable them. Back then there were like three slightly different CLI commands to do it, and it felt like none worked from like 5 tutorial tabs I had open, putting it `experimental-features =` into flake you are trying to switch to does not work obviously.

Then you hit the classic situation where your flake is not committed or staged, so Nix refuses to see it. And instead of telling you that, it prints this abomination of error message "error: path '/nix/store/0ccnxa25whszw7mgbgyzdm4nqc0zwnm8-source/flake.nix' does not exist" (https://determinate.systems/blog/changelog-determinate-nix-3...)

I would not wish learning Nix from zero on my worst enemy, and I say that as someone who uses nix-darwin, devShells, deploy-rs and so on every day. The UX/DX is really bad, but nothing else comes close to its capabilities.

Sorry for rant but without flakes I would not make it.


> The flakes were the main UX/DX improvement for me. Before them I honestly could not do anything.

Agreed. I think flakes are far more intuitive than channels. In a flake everything is declared in the repo it's used in. I still don't understand channels.

For someone who's used to thinking in channels, I suppose flakes would be jarring. For someone (like me) who came from the world of Project.toml and package.json, flakes make a lot of sense.


I think a lot of people come to Nix and NixOS from Linux and similar environments, where having "repositories" or "registries" is fairly common as a way for distributing indexes of software in their distributions. So it's quite naturally moving in that way.

But for someone coming from OSX/macOS or Windows where there basically is just one index (provided by the companies maintaining the OSes) and you can't really add/remove others, it's a completely new concept, makes sense there is at least a bit of friction as those people wrap their head around it.


I'm not sure I understand your point. You're saying that channels are like apt/sources.list or yum.repos.d, and flakes are like the Apple App Store? Or the other way around?

One thing that probably didn't help my understanding of channels was that I run Nix on non-NixOS systems (primarily MacOS and Fedora). If I'd stuck to NixOS, then thinking of a channel in the same terms as apt/sources.list or yum.repos.d would have been an easier mental model.


> your flake is not committed or staged

That has nothing to do with flakes. When I add a "module" to my repos its the same. I have to add it the git repos or nix does not "see" it. And yes, its pretty unintuitive.


It actually is specific to flakes. Classic nix commands can see untracked files just fine. Flake evaluation behaves differently because of how it decides which "scheme" to use:

> If the directory is part of a Git repository, then the input will be treated as a `git+file:` URL, otherwise it will be treated as a `path:` url;

This is why untracked or unstaged files disappear when using flakes:

https://github.com/NixOS/nix/blob/ec6789f9dafce41011418fe6fc...


Interesting.

What's more interesting, is how confident your original comment read, but turned out to not be correct at all. Of course it has always been true, but excellent reminder that even humans hallucinate.

I tried to edit my comment but not possible.

I could have sworn that I had this issue without using flakes. The start with Nixos was really bumpy; I must have mixed something up.


> And instead of telling you that, it prints this abomination of error message

This at the very least has been fixed, I just saw this very error message two minutes ago:

> error: Path 'style.css' in the repository "/projects/blog" is not tracked by Git.

> To make it visible to Nix, run:

> git -C "/projects/blog" add "style.css"

Using "nix (Nix) 2.32.4" on a multi-user CachyOS setup.

Though I do agree Nix still has many paper cuts, and Flakes so far seems to be introducing a lot of them too.


I’m convinced when people say they “love flakes” , 95% of them just love fetchTree and lock files.

(Which is totally valid btw)


Fair, another thing I really like is you can do `nix flake show templates` and try to `nix flake init -t templates#trivial` and be like ahh so thats how its supposed to be done or init `full` and be like ok this flake thing can do a lot of things I didn't know it could do, you can then edit, delete and experiment.



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

Search: