I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt
This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself from version "nix-2.3.10" to "nix-2.3.10-x86_64-unknown-linux-musl" because it saw that package's version string as a version bump. The suggestion in the github issue was to instead use an unofficial third party package for basic package management because this was a known, long-standing issue that is not likely to be fixed.
https://github.com/NixOS/nixpkgs/issues/118481
The experience came across as a massive red flag and I decided not to pursue it further.
I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manager for dotfiles and user dependencies. Using Nix like an imperative package manager is not really an improvement over existing ones, the declarative bit is where it truly shines.
I agree, but I think nix-env is only the tip of the iceberg with respect to bad upfront experiences. If you try to make a Go package, for example, you end up having to provide a hash. To generate the hash `vendorSha256`, you have to run `nix-prefetch`, but that program is broken on MacOS. I mentioned elsewhere that I spent a weekend working with the Nix discord to try to install VS Code with some extensions for Rust development, and we collectively couldn't figure it out (I'm not using NixOS, but just Nix the package manager). In the past I've tried to package a simple Python app thinking it would be a simple reference to a pypi package, and I ended up having to package a never-ending matrix of the most obscure C dependencies and ultimately gave up. Maybe if I were doing Haskell development I might find the Nix happy path, but for now I just have a nix shell that installs a few basic CLI utilities and that's the only way I've managed to use Nix successfully. Further, any time I have to do anything in nixpkgs, I find that everything is a slog--since there are so few imports (and because the Nix people don't believe in documentation or types or even sane file/directory organization), in order to find the "shape" of argument `foo` to the Nix package function `Bar`, I need to grep the whole nixpkgs repo for something that uses `Bar` and then figure out what it's passing in for the `foo` parameter. Often `Bar` is passed to several other functions (defined in several other files) before it's called and the thing that gets passed in for the `foo` parameter might be the return value of a function which itself is returning the result of some other function (each of which is defined in other files), etc. This results in a combinatorial explosion of inefficiently grepping around the codebase just to get the type of a symbol (something that would come for free in a statically typed language).
I'm a big believer in the Nix approach to builds, and that this approach holds a lot of potential for DevOps (especially CI/CD); however, there are so many practical problems with Nix and the community doesn't seem especially interested in fixing them. Of course, what volunteers spend their time on is there prerogative, I could volunteer my time rather than criticize, shame on me, etc but it's a loss for the broader world. Personally I would really like to see a community with the ethos of the Rust community pick up the torch and try to build something inspired by Nix, but perhaps with more pragmatic choices (e.g., instead of inventing an obscure scripting language, they might use something more familiar and thus easier on new users; rather than the chaos of nixpkgs, they might give users a type system and/or good editor tooling; rather than the difficult-to-Google "Nix" label, they might pick something a bit less overloaded; etc).
(author here) I agree that Nix not being statically typed is one of the biggest drawbacks of the language. Having it statically typed with a strong type system like Haskell's would help solve some of the readability issues that you mention. Types of course also serve as documentation, which is another often-mentioned weak point of the language. Finally, with static types we could also have much better editor support with nice things like auto-completion.
Unfortunately, I'm not aware of any efforts to add (optional) typing to the Nix language.