Quoting https://nix.dev/tutorials/nix-language.html:

    The Nix language is designed for conveniently creating and composing derivations – precise descriptions of how contents of existing files are used to derive new files. It is a domain-specific, purely functional, lazily evaluated, dynamically typed programming language.

So, its key features are:

1. domain-specific: designed for conveniently creating and composing derivations. This reason alone already justifies a new language, or an embedded domain-specific language (embedded in the Guile/Scheme for guix), or a mix of both (Starlark, the build language of Bazel embedded in a restricted Python-variant).

2. purely functional: this underlies the philosophy of the Nix package manager, which aims to be purely functional (also known as hermeticity in other build systems, such as Bazel). Being purely functional in turn underlies the congruence of the NixOS operating system, where you declare what the state the system should be in (as opposed to being convergent, so that you specify how to achieve the desired state).

3. lazily evaluated: similar to other build systems (including Bazel), so that you can build only what you need on demand.

4. dynamically typed: this one is controversial. Being dynamically typed—in other words, not developing a type system—gets Nix out of the door first. But users often complain about the lack of proper types and modularity. There are experiments to add a type-and-contract system to Nix, such as Nickel (https://github.com/tweag/nickel).

Most of the above are also listed in the Overview of the One Pager.

Is it that much of a DSL when domain-specific primitives are mostly abstracted away in a standard library written in Nix itself, with underlying machinery written in shell, and when it heavily relies on shell and foreign config snippets to do the job?

Much of JavaScript's underlying machinery is also written in C++, how do you feel about that?

I usually don't need to write C++ when writing in JavaScript, though. Writing derivations in Nix in real world implies using the standard library and writing shell scripts for mkDerivation & co. ("domain specific" shell scripts that use stdenv)

Hmm, I write nix too, but never write shell within nix. Do you use it for custom builders?

How is using (nix?) standard library something that you don't want?

It's worth mentioning that Nix is pretty old at this point, it feels a little younger due to its recent surge in popularity. But 20 years ago (that is 8 years before v8!), the programming languages market looked quite different from today.

Guix shows that it's possible to use a different frontend language technically, but switching the nixpkgs repo itself over to anything else at this point would be an enormous community effort where it's hard to say whether it's worth it.

Yeah. I guess the answer is that there weren't (m)any configuration languages which had functions - even YAML itself (which doesn't have functions) came out a few years before nix. Cue, starlark, dhall are all much later.

The thing that is special about Nix the language is everything it doesn't have (no side effects[1], no state, no mutability). It's a very small and simple language.

Those constraints are really important for the rest of the Nix ecosystem to work.

[1]: technically there is one side effect - putting a derivation (i.e. a recipe for how to build a package) into the nix store.

> Nix only exists to be the language for Nix, the package manager. While people have occasionally used it for other use-cases, it is explicitly not a general-purpose language.

The next question is why is the Nix package manager needed and why should a software developer care. I don't know the answer.

Nix allows you to install packages without naming or version conflicts. It allows you to make source repositories act as first-class packages. It can be installed on any Linux distribution and MacOS. Changing and customizing packages is trivial. All the building and installing happens outside of the source tree, so you don't clutter up your $HOME. It's reproducible. It's simple. And it's build with the needs of Free Software in mind (unlike snap or flatpak which seem mostly concerned with packaging proprietary software). Also Nix is 20 years old at this point.

Simply put, with Nix I can do:

   nix run github:project/name

to run a program. Not many other package managers are capable of that.

That's cool but Brew seems to work just fine for my needs (and most developers on a Mac, apparently). Which is why I think the question still stands; unclear why people should care when the status quo is good enough.

Have you tried Google?

Software developers often want to customize:

1. their home environments: for packages (some reach for brew on MacOS) and configurations (dotfiles, and some reach for stow).

2. their development shells: for build dependencies (compilers, SDKs, libraries), tools (LSP, linters, formatters, debuggers), and services (runtime, database). Some reach for devcontainers here.

3. or even their operating systems: for development, for CI, for deployment, or for personal use.

Nix provision all of the above in the same language, with Nixpkgs, NixOS, home-manager, and devShells such as https://devenv.sh/. What's more, Nix is (https://nixos.org/):

- reproducible: what works on your dev machine also works in CI and in prod,

- declarative: you version control and review your configurations and infrastructure as code, at a reasonable level of abstraction, to specify what the system should be, not how to get there,

- reliable: all changes (switching generations or profiles) are atomic with easy roll back.

Thank you, it makes sense. I guess these points would resonate with me if I had the problems you describe. Fortunately, I usually don't. The less I fiddle with packages, dot files, shell scripts, the better my life is.

It's not really a programming language. It's a lot like JSON except with lambda functions and variables. Compared to the "template yaml" monstrosity gifted to us by the pointy-haired corporations, the Nix language makes a thousand times more sense.