dotfiles VS cargo2nix

> And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...)

I agree that the name is bad and has always been bad. I wonder what they were thinking. But the syntax of the Nix language is not based on Haskell. It would be better if it were, but the Nix syntax is actually based on trying to twist a functional language into looking like a Unix-style configuration file. It's horrible, and conceptually big details like "this is a function" is hidden in very subtle syntax (a single colon). The liberal use of semicolons and the use of space-separated lists is another concession to looking like a config file. I feel Nix would have been better if it didn't try to cater to older conventions in this way. Sometimes the old ways are just bad. Incidentally, one of the big advantages of Guix (a Nix fork/derivative) is that it uses Scheme as its declaration/configuration language.

I switched to Nix some years ago on my desktop system. While I was initially quite frustrated at lots of the paper cuts - particularly the byzantine design of Nixpkgs itself which is built around manual programming with fixed-point combinators - I was carried through by two things:

1) I was intellectually convinced that the basic premise was sound.

2) Getting a basic desktop system running doesn't require you to understand all the complexity. NixOS works really well out of the box with its standard settings, and making basic configuration changes and adding/removing packages doesn't require you to know anything about the Nix language or the design of Nixpkgs.

Not much later I was able to do pretty radical things like changing the version of LLVM used by Mesa on my system, to work around a defect in AMDs GPU drivers[0]. I have no idea how I would do something like that on Debian. Even better, when this workaround later became unnecessary, I just removed the pertinent parts from my configuration file, and it was like it was never there. My system is fully declarative and not soiled by the remnants of previous hacks.

[0]: https://github.com/athas/dotfiles/blob/d495aeb85fe38569eb212...

- Rust projects are built with https://github.com/cargo2nix/cargo2nix. We chose cargo2nix to get incremental builds, meaning that dependency builds can be shared between our Rust projects and that not all dependencies have to be rebuilt when adding/updating/removing dependencies from a project.

We used cargo2nix to generate top-level Cargo.nix file that we committed to the repository (we didn't allow generating nix files on CI for security and reproducibility reasons).

There's a cross compile example that works for at least 3-4 targets on Linux and uses proc macros. Pretty sure the situation you described is no more complex.

Release notes. Last announced release was 0.9.0.

Nix already solves this problem and can handle dependencies and building projects across a range of languages (including Rust via Cargo2nix) and reproducible machine configuration.

Building with nix, for instance with cargo2nix (https://github.com/cargo2nix/cargo2nix), could be safer if sandboxing is enabled.

cargo2nix