* The syntax isnt well liked.
* The package manager relies on global state which kills the use of sharing / over NFS.
* The nixstore treats a filesystem as an object store.
* Related to above, permissions aren't secure as they could be.
Some of these can be worked around, some of them require an entirely new project.
There seems to be no value in a dynamically-typed system description language, but both a practical burden and a degree of unnecessary risk.
Transitioning to a more consciously-designed, statically-typed, still-declarative language should put the project on sounder footing. The existing language interpreter should be easy enough to instrument to annotate all the existing specs with the actual types seen when building the corresponding packages, enabling automatic translation and transition to a better language for almost all packages, excepting only those (probably?) few that actually rely on dynamic-type follies. Those last could stay on the old language, be hand-translated to the new one, or be abandoned, case by case.
In a language like Nix there isn't really a distinction between compile time and runtime anyways and for cases where you want to check the shape of some data you can use e.g. yants[0].
The only difference would probably be slightly better error messages for incorrect type applications on builtins.
Could you maybe elaborate on this point? Or point me to other resources detailing this argument? I'm unaware of details about the cue project: i found it interesting on paper but when i never tried it as i personally consider it's useless as long as you can't validate data against an external schema (like JSON-LD or XML schemas).
> The only difference would probably be slightly better error messages for incorrect type applications on builtins.
Why only on built-ins though? If nix was statically typed, every package could define its own types for configuration/overrides and entire documentation could be auto-generated. I was not aware of yants, it looks great but it sounds like something that would be very useful as part of nix itself (like a nix check command). I love nix/guix as a concept but every time i've tried i've been been put off by severely-unintelligible errors due to bad typing or simple syntax errors (due to my lack of experience of what to use where and lack of documentation on expected types).
> In a language like Nix there isn't really a distinction between compile time and runtime anyways
This is very true, but exactly for this reason Cue's unified approach of having types be values seems like a good thing.
Perhaps Cue is missing the ability to create new abstractions? I guess Turing-completeness may be necessary for this after all.
That's a weird thing to list as a shortcoming, since that's the main innovation of Nix. ("package management as memory management" as the paper and thesis said)
Fourth point is objectively false: there are no setuid binaries anywhere in /nix/store. No setcaps either. One unprivileged user owns everything under /nix/store. I absolutely love this. Installing a new package cannot create security vulnerabilities, because it cannot affect existing packages or their dependencies, no new processes are spawned, and no setuid/setcap binaries are created. Note I am talking about nixpkgs here, not nixos. If you trust sandboxes (like chrome does) then compiling a new package cannot create security vulnerabilities either.
Second point is just an annoyance. It bothers me too, but we NFS-users lost the mindshare battle long ago. It's all HTTP and SSH now.
Fourth you could have each package have it's own user/group