Live data from Hacker News

Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

zero-to-nix.com

41–50 of 227 posts

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#41
post #2

I read of Nix now and then. Seems its more than a fad. Why should I invest time? What makes it stand out?

Closing in on 20 years of existence doesn't really qualify for fad I'm just starting a serious learning journey with Nix after flirting with the idea for a few years. Mostly because I find myself endlessly working on tooling to support the projects I work on that Nix already does extremely well. The feature I am most sold on is the ability to invoke clean complex development environments, that bring themselves to exi…

It may not be a fad, but there's a lot of rose-colored hype that masks a world of tedium. New prospective users should be prepared for a lot of uphill grind with respect to configuring packages or defining their own packages. Every time I try to do seemingly simple tasks in Nix, I end up spending hours on the Nix discord channel trying to work out a solution with seasoned users (who invariably struggle to work out a reasonable solution). Often times I end up having to try to figure out how to package some obscure C dependency deep in the dependency tree with its own bespoke build system and so on. Nixpkgs is also pretty poorly organized (or at least I can almost never find the package I need) and this is pretty critical because something as simple as answering "what type does this function take?" requires a ton of searching around Nixpkgs (largely due to the lack of type annotations or even informal documentation). The CLI tool surface is also not particularly intuitive, and there are different tools for different problems and no consensus about which tools to use (or at least the official docs often disagree with popular opinions in the community). You have to be aware of whether you're just using the Nix package manager or whether you're using NixOS because it will affect the way you write your configuration and often snippets on the Internet implicitly assume one or the other such that you will spend a lot of time trying to fix snippets or find the right snippet for your use case. MacOS is still a second-class citizen in the Nix world and a fair amount of stuff doesn't work properly (although I can't think of specific examples off hand). The Nix expression language seems unnecessarily unfamiliar to mainstream programming languages--I don't object to the functional nature, but I still spend quite a lot of time consciously thinking about syntax even though I've been using Nix on and off for ~7 years now (compared with e.g. typescript which I've barely touched and yet is trivial to read). Normally I don't complain about syntax, but you can do very little in the Nix world without reading and writing a bunch of nixlang and even if the other problems were resolved this alone would make it difficult to sell in most organizations since every developer would have to figure out how to work with it (package management is high-touch).

I'm a big believer in Nix's high-level approach to declarative systems, but the whole UX of Nix is so poor that foregoing declarative systems altogether is quite a lot less painful than using Nix in my experience. I'm rooting for it, but it really feels like Nix needs a product manager or something (no disrespect to the maintainers; these are difficult problems and I'm sure I wouldn't do a very good job). New users should beware.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#43
post #7

> Zero to Nix is opinionated because it advocates learning and using flakes and treating channels as deprecated. I think I need a “Channels to Flakes”. I have an existing system configuration that seems to work fine without flakes. What am I missing out on?

A `flake.nix` file provides a consistent entrypoint to your codebase, which is nice when using Nix generally. For NixOS specifically, you can point `nixos-rebuild` to a flake & have it switch config.

I also find nix flakes have a nicer UX to use. To use a channel, I have to run `nix-channel --add`. But, with flakes, I only have to declare it as an input.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#44
post #36

UX feedback: for an opinionated guide targeted at newbies, I think the 'concepts' page should be much more of a guided introduction. I click on it and have a big basket of things in _alphabetical order_. I think it should be a top-to-bottom ordering of how a user should read them if encountering for the first time. Maybe have a separate glossary page if thats what you are going for with the alphabetical order.

Thanks for this. Our goal is to keep people on the "rails" of the quick start, with the Concepts as a way to fill out knowledge people are curious about. I wonder if we should downplay the concept docs in service of that? Or put more CTA's to go take the quickstart?

If that’s the intention the naming of the quick start misleads me. I typically skip the example at the beginning of documentation and go straight into the meat of it. In this case it sounds like I inadvertently skipped the main content.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#45
post #37
post #13

Earlier quoted context omitted.

In your specific case - a _channel_ versus a flake _input_ - consider how you're tracking your system configuration. If you have an /etc/nixos/configuration.nix, then your system can be reconstituted _only_ if you have that configuration.nix in addition to the revision that your channel is currently on. Compare this with a system defined in a flake's `nixosConfiguration`, which accepts its version of nixpkgs from the…

Is this more deterministic than pointing Nixpkgs at a specific commit/tarball in the configuration? I have often done this to make reproducible builds in other Nix settings and it has worked well.

Yes, because it also makes your Nixpkgs config explicit (doesn't read ~/.config/nixpkgs/config.nix unless you source it in-repo) and doesn't rely on env vars (e.g., NIX_PATH) which are not given explicitly in the flake.

But pinning Nixpkgs alone does get you much of the way there (and for many use cases— those where the only referent on it is 'nixpkgs' or 'nixos'— does make NIX_PATH redundant anyway).

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#46
post #2

I read of Nix now and then. Seems its more than a fad. Why should I invest time? What makes it stand out?

For me, i use it on my Desktop because i love things being stable for my work environment. I don't want an upgrade over the weekend to cause problems come Monday morning. I've had my system get "borked" on updates in the past, and Nix lets me revert very very easily. Also upgrading libraries for one App can easily be isolated from breaking other applications and etc. It's got tons of flaws (to me) , but the core idea…

For me, the "borking" issue is largely resolved by running Btrfs. Just make a snapshot shortly before updating, and then I can revert to it if needed.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#47

Earlier quoted context omitted.

Do you symlink your config repo to /etc/nixos or something else? So far, I've just been rsyncing my config repo folder after I modify it.

I use an update script that overrides that location to $(pwd), and also uses nvd to print a package diff for the update. Among a few other niceties. With flakes, that's a regular nixos-rebuild flag; otherwise it's an envvar. /etc/nixos is just the default, there's a number of ways to set your own path. One of the simplest might be to put "import /home/wherever" as the sole contents of configuration.nix.

That sounds like a nice little workflow; I might have to incorporate something like that with `nvd`...

Though, it should be said that `import /home/wherever` might not work if you switch to / use flakes, as that is likely outside of the flake's git repo (and thus impure).

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#48
post #6

Earlier quoted context omitted.

Thanks, Jorge! I think the nix3 interface and the Flakes solve a lot of UX problems. Maybe we could do a bit of a user study, to see where you get hung up?

What's the `nix3 interface`? I use NixOS with Flakes, but frankly it's quite obtuse lol. I don't even know how to specifically update my `nix`. I updated to the latest release the other week and my `nix` CLI is on `2.11`. Are you referencing a 3.0 version of the `nix` CLI? If is there a summary somewhere on what is different between 2.xx and 3.0? Though i still have no clue how to update to 3.0 if i wanted to. Search…

It refers to the new CLI, i.e. the "nix" command. The old CLI is the nix-* commands (nix-env, nix-store, etc.). The new CLI and flakes are still marked experimental, but the plan is to stabilize them and call that "3.0". So it won't be very different from the current 2.12 - you just won't need to enable some experimental features anymore to get the new CLI/flakes.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#49
post #36

UX feedback: for an opinionated guide targeted at newbies, I think the 'concepts' page should be much more of a guided introduction. I click on it and have a big basket of things in _alphabetical order_. I think it should be a top-to-bottom ordering of how a user should read them if encountering for the first time. Maybe have a separate glossary page if thats what you are going for with the alphabetical order.

Thanks for this. Our goal is to keep people on the "rails" of the quick start, with the Concepts as a way to fill out knowledge people are curious about. I wonder if we should downplay the concept docs in service of that? Or put more CTA's to go take the quickstart?

I like the idea of having a flow through, at least, some of the concepts in the order they should be introduced.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#50

Earlier quoted context omitted.

For me, i use it on my Desktop because i love things being stable for my work environment. I don't want an upgrade over the weekend to cause problems come Monday morning. I've had my system get "borked" on updates in the past, and Nix lets me revert very very easily. Also upgrading libraries for one App can easily be isolated from breaking other applications and etc. It's got tons of flaws (to me) , but the core idea…

For me, the "borking" issue is largely resolved by running Btrfs. Just make a snapshot shortly before updating, and then I can revert to it if needed.

My problem is i don't know what gets borked immediately after updating unless it's catastrophic. Ie i've gone a fair bit of time before i realized some specific functionality of some program no longer works due to some unrelated change in an underlying dependency that i was unaware of. Oof.

Granted Btrfs sounds great though, i've not used that. It would certainly help.

Post reply on HN