[nextos]

I think Nix is getting an unfair reputation for being too hard. Simple things are IMHO simpler in Nix than in any other distribution, and what one needs to know to accomplish them is tiny. It has basically reduced my sysadmin maintenance tasks to zero. In case of regressions, Nix makes it trivially easy to go back in time 2 or 3 years, cherrypick some packages and install them, or change your entire desktop environment, and then go back to the previous state with no effort.

Nix is hard if you need to build something difficult to package or something that has very unusual or dirty build processes. If you need to that regularly, Nix is not worth the effort unless you are an organization that values reproducibility and is prepared to pay for its cost upfront. If these particularly messy usecases are something that you don't encounter so frequently, you can always use an escape hatch to be able to make your install impure. For instance, distrobox is quite convenient to run e.g. an Arch or Ubuntu container. In my case, this has been helpful to run Julia, whose Nix packages are quite brittle.

[davidcox143]

I've been using Nix and NixOS since 2022. I can't imagine not using Nix at this point and agree that the reputation for "being too hard" is not quite accurate. Nix is different - that's the point.

The learning curve is a thing, although I'd argue that it's nowhere near as steep as the tools many of us use every day (C++, Rust, AWS/GCP, etc.)

Nix's "difficulty" IMO comes from defaults that are not sane and a split community. For example, if you use the official Nix installer, flakes are not enabled by default (despite being widely used [1]), but they are if you use the Determinate Systems Nix installer.

Flakes are realistically the only way to obtain the benefits that motivate learning Nix (deterministic pure builds, fine-grained control over dependencies) and are the "primary driver of Nix's adoption" [2]. AFIK there isn't a viable alternative to flakes other than maybe atoms [3], which are relatively new (like "lock files are totally hand made" new [4]). Yet, the official Nix stance on flakes is to wait... for... what?

For a day-in-the-life look at more of Nix's rough edges, I posted some rambles here [5].

[1] https://x.com/d4r5c2/status/1896415101386928539 [2] https://x.com/grhmc/status/1896551138104844389 [3] https://x.com/nrdexp/status/1925892763301695978 [4] https://x.com/nrdexp/status/1925707692447871283 [5] https://youtu.be/TwVamLq5OHY

[codethief]

Do you have a link that explains what atoms are? This is the first time I'm hearing about them.

[davidcox143]

Sort of. There’s a summary by the author of atoms in the Twitter thread linked above.

They also link this very lengthy blog post:

https://nrd.sh/blog/atom-anatomy/

My understanding of atoms compared to flakes is that they 1) add toml 2) provide a more precise way to reference remote src.

The author also claims performance benefits. I haven’t used them personally and can’t speak to their stability or ergonomics.

[codethief]

Thanks!

[nylonstrung]

I like your Atoms idea and will follow along

IMO 80% of Nix's shortcomings are due to 20 years worth of tech debt that we're all very conscious of

By 2030 all the rust rewrites and new tooling will have finally saved us from it

[bfrog]

Unless it becomes a typed language with clearer syntax around what is what, it’s painful at the scale of nixpkgs and nix without nixpkgs just isn’t all that useful.

[nylonstrung]

https://nickel-lang.org/ is a configuration language similar to a typed Nix

I'm hopeful something like this could get adopted in future Nix tooling

[jrockway]

I think the reputation is fair. Why is flakes still experimental, for example? That's a subtle bit of encouragement to do things the old way and as a result, documentation is always mixed and you end up "but how do I do that in a flake".

Something that is in theory nice is using the same packages in development and production. But "everyone" uses Mac OS for development and Linux for production, and if you want to guarantee that every developer on your team isn't recompiling Node from scratch, you want to use nixpkgs-25.05-darwin instead of nixos-25.05 on Mac OS. The result is that you aren't actually getting the same package across systems, which is rarely problematic but is something that Will Go Wrong someday. Why not keep Darwin stable in the main stable branch?

I have also found the entire system incredibly unstable during release pushes. Lots of stuff broke in 24.11 and unstable as 25.05 was being prepared (notably nodejs_20). What I learned from this experience is "don't touch package updates in May or November" which isn't amazing if you care about security updates.

So basically, Nix is incredibly rough around the edges. nixpkgs is a much better package repository than anything else I've used, but it's not perfect. It's generally more up to date than Debian unstable. It supports more platforms than Homebrew (which doesn't work on linux-aarch64, a platform I use heavily). Overall the philosophy of making each package entirely self-contained is the right approach.

NixOS is also fine, mostly... but I use Bazel to build all my personal projects. Bazel does not work well on NixOS. For some reason, nixpkgs doesn't have Bazel 8 which is the version I use (because if you don't update your project to a recent Bazel today, you'll have to do it tomorrow). If you get a NixOS-compatible bazel 8 from some random flake, you can solve that problem. But then there are a lot of assumptions the Bazel ecosystem makes, and those are unresolveable. To the Nix folks, having your build system download the official distribution of Go, verifying the sha256, and execing it to do your builds is unthinkable. Personally, I'm fine with it. The Go team knows how to release Go better than anybody. But this impedance mismatch makes it nearly impossible to have a project that builds on "normal" Linux and NixOS. You can go full Nix and get go, c++, etc. from nixpkgs, but then everyone has to have Nix before the can work on your project. I would be OK making that decision for myself (I already use Nix), but I imagine it's a hard sell if you just want to fix development at work. People would complain. People will run into problems. To some extent, this is Bazel's fault (and the ecosystem) for assuming that /bin/bash and some vaguely recent /lib64/ld-linux-x86-64.so.2 exists. NixOS says "no it doesn't unless you declare it and get it out of $PATH" but honestly which version of bash runs "exec bazel-out/program-that-was-just-built" is irrelevant in practice, so it's just an unnecessary barrier. There is an attempt at compatibility for those that don't care about versioning the version of Bash that each shell script runs (envfs, nix-ld), but at least for me, it doesn't work. All in all, the net result is that I can't actually do work on NixOS, and I can't write a flake so my home-manager configuration can install all the software I've written for myself, which is a pretty bad feeling. Building my projects is easy... "git clone [e-mail]:jrockway/monorepo; cd monorepo; bazel build //jlog/cmd/jlog; cp bazel-bin/jlog/cmd/jlog/jlog_/jlog ~/bin". But it's literally impossible on NixOS simply because something in the 10,000 lines of other people's code wrote "#!/bin/bash" somewhere. That's pretty rough.

My TLDR is if you want the latest version of Git on Mac OS, linux-aarch64, and linux-x86_64, you should probably look at nixpkgs and home-manager. I like 'em. I don't think there's anything better. Everything else... it's rough. When you commit to leaning into Nix, a lot of your free time is going to disappear for a while.

[nylonstrung]

Hopefully Nix and Bazel can learn to play nice. There have been 5 talks on this in the last year alone, so I think many others are in your same boat

https://youtu.be/2wI5J8XYxM8?si=HS0YKewPz-Mmhptn

https://youtu.be/6xWr8f2RhX0?si=sNjkJ-rwLfTI97AP

https://youtu.be/FoSCSQO5xhI?si=pHmZJjKS-mX87iyn

https://youtu.be/6qOoOsjmyZ0?si=sVppXxb1E3ml7TBk

https://youtu.be/s801fgQOGnw?si=E--1aVJyUDjjOFWW