Stop being lazy, go back to engineering first principles and it makes little sense to stay with Nix. Guix or any rewrite as a library in a well-developed language* makes more sense.
*For example, why are Haskellians using Nix so much instead of integrating its concepts into their own tooling?
https://blog.ezyang.com/2016/05/announcing-cabal-new-build-n...
https://cabal.readthedocs.io/en/2.0/nix-local-build-overview...
Also cabal isn't positioned to be a system level package manager. Haskell programmers are the type to want both their application builds and system dependencies to be reproducible and predictable.
> Stop being lazy, go back to engineering first principles and it makes little sense to stay with Nix. Guix or any rewrite as a library in a well-developed language* makes more sense.
Getting Guix packages to be as complete as nixpkgs isn't a matter of laziness though. One person wouldn't be able to do it no matter how disciplined they were.
Stop being lazy, go back to engineering first principles and it makes little sense to stay with C. [Insert systems programming language du jour] or any other well-developed language makes more sense.
https://github.com/tvlfyi/tvix
To me, the perfect solution would be to have a base like Nix/Tvix you can build on top of, for example to make a package manager for your language, and have the users of that language's PM interact with TOML or JSON.
It's the need to maintain super legacy systems and interoperability. There are entire CPU architectures that LLVM does not support and are only commonly supported by C and these things are still everywhere and are really gnarly problems to replace them.
Even if you throw everything away on the software side and start over from scratch, that's going to _force_ you to replace some hardware somewhere that you won't or can't replace.
It's literally just typed JSON with functions and a few built-ins. It's laughably simple and great. The whole "yet another programming language" refrain is so silly when it comes to Nix.
The fundamental difference with Guix is that evaluation (what they call "host code" -- everything that happens BEFORE the .drv is written) is wildly impure.
Guile code can access the network, write to the filesystem, heck it can even pull bytes from /dev/random. It can delete your home directory or email your ssh private keys to Zimbabwe.
The Nix language, by contrast, is incredibly restricted in order to make evaluation a deterministic function of the .nix source code you give it, things whose cryptographic hash is in the .nix source code, and nothing else. There is an --impure flag which lets it read from (but not write to) the filesystem but nixpkgs does not use that.
That is a pretty big rift that I find myself unable to cross. I can eval Nix code from any random bozo on the interwebs without having to trust them. If I trust the nix sandbox (which I mostly do) I can even build the resulting drv. I can be sure that evaluating that Nix code will produce exactly the same drv two years from now that it did today. Guix doesn't offer those things. Because scheme. I'm sorry but scheme just isn't the right language for this, it's too powerful.
That's a bug not a feature.
Every language these days is trying to force you to use its own badly-implemented imitation of Nix. Just look at what cargo does with the target/ directory and wonky "build fingerprints".
It's madness.
As it is, the rust-in-Nix and bazel-in-Nix stories are both pretty terrible, while the Python one is actually not too bad: https://github.com/nix-community/poetry2nix (barring these 4000 lines of horrible hacks: https://github.com/nix-community/poetry2nix/blob/master/over... and these 27000 lines of telling Nix which Python buildsystem every package ever happens to use: https://github.com/nix-community/poetry2nix/blob/master/over...)