Nix is the ultimate DevOps toolkit

To make it clearer, he is saying that he does

with { foo = "bar"; };

instead of

let foo = "bar"; in

The differences here so other people can follow along.

1. with will not shadow variables defined higher up. This can be either desirable or very confusing.

2. let is recursive by default, meaning you can reference other variables in that block. This behavior can be mimicked with `with rec {}`

[1]: https://github.com/tweag/nickel

You can also stub the hash (e.g. with lib.fakeSha256). nix-build will fail with a hash mismatch and tell you the correct hash.

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,

That's tricky with e.g. IntelliJ as well. For development, I now just use rustup and use nix-shell/nix devshell to define native dependencies. Outside development I do full Nix builds with crate2nix or Naersk.

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.

Python in Nix is painful for various reasons. One is that since the Python interpreter cannot handle multiple versions of a package, nixpkgs can only have one version of each package. However, since many Python packages do not follow semver, it often requires a lot of patching. And then there are issues like Python packages writing directly to their package directory (which does not work with a read-only store). I think packaging Python packages with Nix is worthwhile, but for Python development I think it is easier to just build an FHS environment and use regular Python packaging tools (pip, Poetry, etc.).

This is an issue with some other language ecosystems as well, their packaging models are incompatible with Nix.

This results in a combinatorial explosion of inefficiently grepping around the codebase just to get the type of a symbol*

nix repl* has helped me in many cases. But I agree that Nix would be so much nicer with static typing.

however, there are so many practical problems with Nix and the community doesn't seem especially interested in fixing them

I think most of us are interested in fixing problems. It's just that nixpkgs is large and people have deployed various Nix versions. So, it is quite hard to make fundamental changes to Nix (e.g. typing) and roll them out. Things are happening, e.g. flakes provide a standard interface to package sets, there is work on supporting content-adressed outputs (outside fixed-output derivations), but with the size of the Nix ecosystem, these things take a long time to crystallize and roll out.

It's not perfect, but it works, its fast, and its better than the alternatives.

I'm interested in rying Guix at somepoint instead as I think using Guile might be easier than learning the Nix language, cli tools, and more. I think guix could do much what I do now as well.

I can't see myself using guix as an OS though, since they seem to think systemd is evil or something, and really systemd is quite nice in practice in my experience.