Here, take this wall of text:
nixpkgs || rustup || nixpkgs-mozilla
NixOS has Cargo and the rust compiler packaged, so using the packages
cargo rustc gcc from nixpkgs (see further below on how to use them) you should get an environment that enables you to compile Rust code. The main disadvantage of this is that the Rust nightly releases are not packaged, and it is quite common in the Rust ecosystem for crates to depend on experimental features and thus the nightly Rust compiler.
Then there’s rustup, a tool provided by Rust upstream to manage the Rust tools on your system. This is basically a package manager by itself. It provides the cargo und rustc binaries and dynamically points them to some downloaded version in your home directory. This is probably the best way to get a nightly Rust toolchain, if you don’t mind using a different package management tool.
Some more detailed information on rustup on NixOS: The thing is a bit tricky, because the downloaded binaries make some assumptions about system, that are not met on NixOS. Fortunately the rustup packaged in nixpkgs fixes this by patching the downloaded binaries on the fly to work on NixOS.
nixpkgs-mozilla is mostly just a repository containing additional packaging information for Nix on how to obtain the latest Rust tools as binaries and patch them to work on NixOS. This is a bit similar to a PPA on Ubuntu, as it contains additional Nix packages that are not available from the main package sources, nixpkgs.
This is mostly useful in cases where you need a nightly release, but also want to use the Nix package manager, for example to share your build environment with collegues or CI workers.
The Nix expression required to use it is indeed a bit more complicated involving overlays and stuff. I won’t go into detail here, because using nixpkgs-mozilla should not be necessary in most cases, but this is also described in one of the
shell.nix examples above.
nix-env || NixOS || nix-shell
There are lots of different ways to use Nix to make some package available in your PATH. They all serve different purposes.
nix-env is a tool that can directly manage a Nix profile (each user can have one), and add packages to it imperatively. After adding a package to your user profile with
nix-env -iA nixos.<package>, it will be downloaded from a binary cache (or built, if binaries are not available) and made available in the PATH.
You probably only want to use this when using Nix a non-NixOS Linux distribution, because you can not take advantage of the declarative nature of NixOS when using nix-env.
NixOS, as you probably know, is a Linux distribution that uses the Nix package manager to manage the whole system including system packages and configuration files. On NixOS, you can use your NixOS configuration files to declaratively set up the system and user profiles as well. This has many advantages compared to nix-env, for example you can put the configuration in a git repository or share it between multiple hosts. It also ensures that the packages in your profile are updated when you do
nixos-rebuild switch --upgrade, which is not the case for nix-env (!).
nix-shell is a tool that allows you to set up an ad-hoc environment (a shell with a set of environment variables). You tell Nix what packages you need, it takes care of fetching them and putting them in your PATH for the duration of the nix-shell session. You can do this by running
nix-shell -p <package1> <package2>. This is temporary and the packages may be garbage-collected after the nix-shell has been closed, if they are not referenced anywhere else.
I always set a shell alias from
nix-shell -p, so I can just say
use cargo rustc gcc.
nix-shell can also be used with a Nix expression in a file. If a
default.nix exists in the current directory, executing just
nix-shell will load the environment described in the file. This is useful for shareing build environments with other people, and it can contain more complex definitions, overrides and project-specific version requirements. Some people already posted good examples of