NixOS for sure, it's poorly documented and even worse designed.
Although I like NixOS, I have to agree with the documentation being crap. Which wouldn't be so bad if it weren't so damn different. I mean, other distros have bad documentation, I just read some man pages or check the Arch or Fedora docs.
NixOS does have poor docs, but why don't you elaborate on why you think it's poorly designed?
I have read that in the past, and I do agree with points of it, but I don't agree with the conclusion that Nix is poorly designed. A lot of the issues are in my opinion fairly minor considering the scope of Nix, and many of them are a matter of opinion.
Build system issues
Nix uses builders, which are functions that exist for different languages and frameworks. These build packages for these frameworks in consistent ways, they are documented in the Nixpkgs manual. Nix and Guix seems fairly equivalent here.
Language issues
I can agree with some parts of this, Nix is not a fantastic language imo. I don't think that it is a problem that Nix packages use shell scripting, as it is simpler to me than writing these parts in Guile and any Nix contributor is almost certainly familiar with bash already. I think the upcoming alternative language Nickle looks promising, mainly due to its static typing and improved standard library. I personally find Nix's json like syntax much simpler for basic configuration that Guix, and Guix is not enough better at more complex tasks to be worth it for me.
Debugging
Nix errors aren't great, but errors like infinite recursion are avoided by following good practices. I personally haven't had any errors that I found difficult to debug with a stack trace.
Grafts
I know that Nix does have a similar feature, but I don't know how it works and what its capabilities are in comparison to Guix. I think the amount of package rebuilds some updates cause is a problem, but we currently have the infrastructure to handle it and in practice it has not been a problem for me.
nix-env
Nix-env does not have a proper replacement because the community really doesn't have much interest in improving the UX of imperative workflows. nix profile is meant to replace it, but this will take some time as the nix3 cli is stabilized.
Bad UX
I wholeheartedly agree with your opinion on the deprecated tools. The nix2 vs nix3 cli debate is quite controversial unfortunately.
I disagree though that the current nix3 cli is a bad experience. I find the nix [command] syntax easy to use and understand.
To me this write up seemed like more of an argument that Guix is better than Nix, rather than Nix as a whole being bad. Guix seems great, but I chose Nix over Guix for one major reason, software availability. I prefer free software, but I'm not willing to not use proprietary software and not discuss it in Guix communities. Nix still has great support for things like Nvidia drivers and Steam, which seam difficult to use in Guix.
Also, does Guix have a feature comparable to Nix Flakes? The ability to manage projects and multiple systems with Flakes is Nix's killer feature for me.
I recently switched to NixOS and GNU Guix was also a possible option, and while in retrospective, I can agree with your points, there were two things NixOS does that I want that Guix doesn't offer:
Non-free packages (though I guess I could have used Nonguix)
An option for Secure Boot
I don't think the assessment "it's badly designed" is fair and your conclusion
Years and years of technical issues plague the project and there seems to be little interest in actually resolving these issues. Guix is comparatively much newer, yet the UX is much better and there are constant improvements in many areas. It also has the advantage of being built from the ground up with a clear design mind."
(emphasis mine) is misleading ; it's not better despite being newer, it's better because it is newer and was able to learn from Nix and improve upon it. Also what would you call the Nix whitepaper if not the design behind Nix?
Do you also feel this way about Guix' documentation?
Guix's documentation needs a lot more work for sure, but it's definitely better.
NixOS for sure, it's poorly documented and even worse designed.
Although I like NixOS, I have to agree with the documentation being crap. Which wouldn't be so bad if it weren't so damn different. I mean, other distros have bad documentation, I just read some man pages or check the Arch or Fedora docs.
NixOS does have poor docs, but why don't you elaborate on why you think it's poorly designed?
I have an entire writeup on the issue. https://github.com/CuBeRJAN/nix-problems
I have read that in the past, and I do agree with points of it, but I don't agree with the conclusion that Nix is poorly designed. A lot of the issues are in my opinion fairly minor considering the scope of Nix, and many of them are a matter of opinion.
Build system issues Nix uses builders, which are functions that exist for different languages and frameworks. These build packages for these frameworks in consistent ways, they are documented in the Nixpkgs manual. Nix and Guix seems fairly equivalent here.
Language issues I can agree with some parts of this, Nix is not a fantastic language imo. I don't think that it is a problem that Nix packages use shell scripting, as it is simpler to me than writing these parts in Guile and any Nix contributor is almost certainly familiar with bash already. I think the upcoming alternative language Nickle looks promising, mainly due to its static typing and improved standard library. I personally find Nix's json like syntax much simpler for basic configuration that Guix, and Guix is not enough better at more complex tasks to be worth it for me.
Debugging Nix errors aren't great, but errors like infinite recursion are avoided by following good practices. I personally haven't had any errors that I found difficult to debug with a stack trace.
Grafts I know that Nix does have a similar feature, but I don't know how it works and what its capabilities are in comparison to Guix. I think the amount of package rebuilds some updates cause is a problem, but we currently have the infrastructure to handle it and in practice it has not been a problem for me.
nix-env Nix-env does not have a proper replacement because the community really doesn't have much interest in improving the UX of imperative workflows.
nix profileis meant to replace it, but this will take some time as the nix3 cli is stabilized.Bad UX I wholeheartedly agree with your opinion on the deprecated tools. The nix2 vs nix3 cli debate is quite controversial unfortunately. I disagree though that the current nix3 cli is a bad experience. I find the
nix [command]syntax easy to use and understand.To me this write up seemed like more of an argument that Guix is better than Nix, rather than Nix as a whole being bad. Guix seems great, but I chose Nix over Guix for one major reason, software availability. I prefer free software, but I'm not willing to not use proprietary software and not discuss it in Guix communities. Nix still has great support for things like Nvidia drivers and Steam, which seam difficult to use in Guix.
Also, does Guix have a feature comparable to Nix Flakes? The ability to manage projects and multiple systems with Flakes is Nix's killer feature for me.
I recently switched to NixOS and GNU Guix was also a possible option, and while in retrospective, I can agree with your points, there were two things NixOS does that I want that Guix doesn't offer:
I don't think the assessment "it's badly designed" is fair and your conclusion
(emphasis mine) is misleading ; it's not better despite being newer, it's better because it is newer and was able to learn from Nix and improve upon it. Also what would you call the Nix whitepaper if not the design behind Nix?
Do you also feel this way about Guix' documentation?
Guix's documentation needs a lot more work for sure, but it's definitely better.