I personally switched to hjem, also zig or rust aren't faster by themselves, since llvm can also be used for C++.

I mostly use it for coding so nix run ., I use comma for apps I need just once

Honestly pretty much never, i always use nix shell if i want to quickly try and run something without commiting to it.

Personally I find home manager really hard to use. The documentation is really bad, and I never find what want... Nor what's possible. I don't use it because I don't want to, just I don't know how to

It was that or spaghetti an override and compile krita from scratch. So I chose the lazy way

That's funny. I also use it (semi-)regularly for Krita, Inkscape, MusicBrainz Picard, LibreOffice, and well, not Prism Launcher but Luanti.

I also have GIMP and some other games in the rotation.
My metric is kind of that if I don't use a piece of software as often as I update my system, then it's not really worth including into the system updates. Of course, I also have to not mind waiting for it to be installed, when I do want to use it.

I use comma very frequently. I have fast enough Internet that download time doesn't really matter for most things, so it takes a lot for me to actually promote it to a system package

Ah for these tools I went full all in on home manager! But nothing wrong with a nix run if it works!

I never tried flatpacks on nixos, curious idea! Might solve the one or other flake hack I have :D thanks!

Yeah I see it when I nix run krita lol

I actually use it to run krita, prism launcher when the Minecraft mood peek in, inkscape, MusicBrainz picard, Alistral, peazips, libre Office.

Aka, anything that I don't use enough to warrant opening my config and adding them in (and forgetting when I do open my config.

Although krita is currently being installed through flatpack because nixpkgs ship broken alpha versions...

I do this and then regret it when I'm on my laptop using slow WiFi and have to dowload 1g of stuff to run freecad or Krita or something

I like to include memtest in my boot menu:

boot.loader.systemd-boot.memtest86.enable = true;

You can also use it with grub:

boot.loader.grub.memtest86.enable = true;

I use nix-shell -p for infrequently used commands, or nix shell flake#packagename for flakes. I prefer the shell environment because I rarely need to run something only one in a session. Usually I forget the cli arguments, and then have to run --help and so on.

For anything I need more frequently, I usually install either via home manager if I care about a specific/newer version, or just as a system package (I don't use NixOS).

Same as you but with nix-shell -p

I don't have any packages like that to be fair but: no.

I've ran nix run perhaps .. once a year for the last years. I either create a shell.nix or add it into my config.

Just curious what would be a command you're using like this? The only one that came close to that for me was nvidia-smi and that I ran once with run and then created a shell.nix with some other debug stuff :D

nix-du does it iirc

CppNix isn't slow because of C++, it's slow because its evaluation strategy (tree-walking an AST without any optimizations) is slow. Rewriting in Zig or Rust will not necessarily help; the structure of the compiler needs to be better. That said, Tvix is a Rust rewrite which uses a bytecode interpreter, and it is faster, but it's not a drop-in replacement like Lix. I prototyped a faster evaluator in RPython; see this LixCon 2026 video for my summarized notes to the Lix community.

Nix store transactions will never be instant. You've probably never thought about atomicity and durability for your configuration-file edits, but it's a desirable thing, right? Nix writes to a SQLite database for every transaction. This is not going to be a big part of your runtime as long as CppNix is so slow at evaluation, but it's the reason why trivial builds, like your derivations that merely copy text to the Nix store, take so long.

To add to the other answers, when I'm experimenting with some configuration a lot, I sometimes change it from being Nix-managed to just plain config file. That way I can try things out in a much shorter loop. When I have the configuration that I want, I port it back to Nix. Not a perfect solution, but it can save some time

Personally, I feel that over time this becomes less of a problem. It was very annoying for me as well, but as you get used to the language and the ecosystem, you get better at it and you will need less rebuilds to incorporate something into your config. And if it's only every couple of days, then I am completely fine with waiting 10-30 seconds for the rebuild.

If I'm trying to brute-force my way through something I usually continue to look for the next possible solution while the system is rebuilding, so it doesn't feel like time-loss to me.

In my world that kind of transpilation should be instant.

Well, as you've guessed, it's not really just a transpilation. A NixOS rebuild evaluates significant parts of Nixpkgs, <nixpkgs/nixos> as well as your configuration from scratch (technically flakes have evaluation caching, but it's not fit for purpose).

Nix isn't a fast language to begin with, but the evalModules call that actually takes your configuration and turns it into a package that can be built is very expensive. Because NixOS imports (almost) all modules by default, it has to do deep merges of most of <nixpkgs/nixos>, which amounts to almost 32 MB of Nix code. Everything else is a rounding error compared to that.

Oh, and it has to do this for Home Manager too, because Home Manager is also built on evalModules and also imports all the modules. As is flake-parts if you use that (though in that case the set of modules is small so you it's much less noticeable).

How much of speedup would it yield to rewrite Nix and/or home-manager in a faster language like Zig or Rust?

It would probably make the performance worse before making it better. Nix is slow but it's not because of the implementation language (which is C++), you would have to do actual interpreter engineering (e.g. writing a JIT) to make an interpreter much faster than the current one.

A builtin (C++ instead of Nix) implementation of evalModules would probably help, but nobody wants the versioning headaches that would come from that. I'm also not sure it would do that much, the amount of data is just massive.

A more promising optimization is to make NixOS not import all the modules by default, but efforts to do this haven't really gained traction. Probably because you pretty much have to check all modules for cross dependencies.

As a user the best thing you can do right now is using Home Manager standalone and not as a NixOS module. That way, while switching generations will still be slower than it really should be, at least it won't evaluate and merge all NixOS modules every time you change your mind about a background color.

You can also use a non-Nix-based dotfile manager and forego Nix evaluation (and building) entirely. The only thing you really lose is being able to remote deploy dotfiles with things like nixos-rebuild build-vm.

Nix-specific shell aliases: nixls is 'cd /etc/nixos && tree *.nix(wrong tree syntax hut you get the gist)nixrs` is a function that...

• runs git add . and git status in /etc/nixos
• runs nixos rebuild-switch --flake
• returns you to whatever directory you were in

lib.mkIf for optional configs

Using let ... In {} more often, basically treating nix as a programming language instead of a config language

Heads up: when I upgraded network name resolution broke. It looks like the problem was services.mullvad. Unfortunately booting into an old generation still left me in a broken state. I guess there is some non-declarative state set. If you get into this situation there is a recovery procedure given here: https://github.com/NixOS/nixpkgs/issues/314694

No problem! We've all been there!

I usually prefer to use nix, as it's a real language and basically serves as macro language/preprocessor for the configs that don't have functions or such (obviously in this case Lua does) . So it gives me everything in one language (thank I generally kinda like), with proper highlighting, I can reuse code, and I can more easily cross reference between different services/apps.

That said, I didn't know hyprland was going to make this switch. I guess I finally have to go see if I will like niri.

Yeah, you're right. I completely misread that and I've been barking up the wrong tree. I guess that makes this a nixpkgs-xr conversation rather than a flakes one. Thanks for pointing that out.

It looks to me like 696b10c removes the filter that previously skipped the xrizer-fix-aarch64 patch. So I would expect that patch to be applied in the latest nixpkgs-xr