Nix: Proposal: give a dedicated name to Nix Expression Language

[ericsagnes]

Nix expression language is often shortened to nix in external material.
Having the same term used for two different things (package manager and language) can lead to confusion, specially with newcomers.

A few examples:

• tour of nix is referring to nix expression language
• nixpill 3

Really, why doesn't nix have basic operations such as division? Because it's not needed for creating packages. Nix is not a general purpose language, it's a domain-specific language for writing packages.

Having a dedicated name for the Nix expression language would remove this ambiguity.
A natural candidate is NixEL.

[lethalman]

I don't understand, Nix is the name of the language. What does it collide
with? Community calls tools with the name of the tools, like nix-env,
nix-build, nix-shell.... nix is nix, and that's already the language name.

On Sat, Mar 5, 2016 at 9:14 AM, Eric Sagnes [email protected]
wrote:

Nix expression language is often shortened to nix in external material.
Having the same term used for two different things (package manager and
language) can lead to confusion, specially with newcomers.

A few examples:

• tour of nix https://nixcloud.io/tour/?id=1 is referring to nix
  expression language
• nixpill 3
  http://lethalman.blogspot.jp/2014/07/nix-pill-4-basics-of-language.html

Really, why doesn't nix have basic operations such as division? Because
it's not needed for creating packages. Nix is not a general purpose
language, it's a domain-specific language for writing packages.

Having a dedicated name for the Nix expression language would remove this
ambiguity.
A natural candidate is NixEL.

—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nix/issues/835.

NixOS Linux http://nixos.org

[ericsagnes]

In the manual, the language is referred as the Nix expression language:

The Nix expression language is a pure, lazy, functional language.

And Nix is used for the package manager.

Nix is a purely functional package manager.

"Nix expression language" being quite long, it is normal that people shorten it to nix.

So in current state it is hard to make a web search targeting only the package manager or the language.

Community calls tools with the name of the tools, like nix-env, nix-build, nix-shell.... nix is nix, and that's already the language name.

nix-env, nix-shell and other commands will be merged into a nix command with #779.

Seeing persons new to Nix/NixOS getting confused by this was the motivation of this issue.
Maybe I just met a minority and this works well for the majority, in that case I see no problems in closing this issue.

But it seems pretty common to have different names for a language and its package manager:

• haskell cabal
• python pip
• rust cargo
• ruby gem
• php composer

The relation between Nix and the Nix expression language is closer to a compiler - language one, but even so it is quite common to have different names for a language and its compiler:

• c gcc
• haskell ghc
• rust rustc

[copumpkin]

:+1: it's currently confusing when someone asks me what Nix is. Never sure whether to describe it as a package manager or purely functional language, so I just say it's both, and then make a point to say "Nix _the language_" (when talking about evaluation semantics, purely functional laziness, etc.) or "Nix _the package system_" (when talking about operational concerns like the store, nix-env behavior, build isolation, etc.)

[vcunat]

I'd personally think that using "Nix language" is fine enough, in those cases where it might be ambiguous, and we should clarify the problematic occurrences. The language isn't meant to be used anywhere else or have a different compiler/interpreter, so I don't see the importance of separating them.

[copumpkin]

The thing is, I'd love to use it elsewhere, in many of the same places people are proposing to use jsonnet.

[edolstra]

@copumpkin You probably shouldn't, it's not intended as a general purpose language :-)

But I agree we should use "Nix language" instead of "Nix expression language", and "Nix file" instead of "Nix expression".

[copumpkin]

I'm not saying to use it for general purposes! I'm saying to use it for the same sorts of thing jsonnet is used for, which is roughly to factor out annoying duplication in config across a wide range of programs. It seems to work beautifully there.

[vcunat]

And why not still call it _Nix language_ and use nix-* for evaluation?

[copumpkin]

I can! It's more confusing that way :smile: I'd also rather be able to integrate the evaluator into other software without having to use a subprocess, but I'll survive.

[vcunat]

I assume libnixexpr.so should be able to do that, even though there are no guarantees for API stability AFAIK. (And one might have to deal with GC-related issues.)

[Profpatsch]

I use nix for the package manager, nixpkgs (nix packages) for the package set, nixos (nix ou es) for the distribution and nixexprs (nix expressions) for the language.
That’s a quite good distinction, don’t you think?

[ericsagnes]

@Profpatsch yes, I think it is good way to differentiate it when there is some ambiguity. My point was more to have an official easy to differentiate name so external materials would be less confusing for newcomers.

Anyhow, as Nix is widely spread and used for both the language and the package manager so I guess it is just a thing they have to get used to :)

I am closing the ticket, but thanks for all the comments.

[ehmry]

Something that might need a dedicated name is the infrastructure under Nix, the stuff shared with Guix.
That is perhaps another issue...

[Profpatsch]

@ehmry That’s the nix package manager, so just nix.

[vcunat]

No; guix only shares a part of nix, I think. But it doesn't seem to matter much – I haven't even noticed anyone wanting nix and guix alongside of each other.

[Profpatsch]

I haven’t taken a look at guix, but I still don’t get why people want that apart from doing their own thing and using scheme.

[vcunat]

I think there _are_ a few technical advantages on guix side:

• The EDSL approach – embedding in a common language – gives you easier access to tools, e.g. editor and debugger support.
• IIRC they use the same language for both evaluation and builder layer, instead of our using nix and mostly bash, making it easier for the layers to collaborate.

... but I assume most guix contributors "chose" for different reasons.

[ehmry]

I mentioned the stuff underneath because there was a discussion about the abstraction between Hydra and Nix at one of the Berlin meetups. The build farm and the farm frontend don't need to know anything about the Nix language, they just needs to parse derivation files (though the language is required to submit jobs), so this a point where infrastructure can be deduplicated and simplified between Nix and Guix.

[DrRibosome]

I know this is closed, but going to propose "nixlang" as a convenient abbreviation

[Ericson2314]

nix + expr = nixpr :)

[ArtemShpytiak]

"...nixexprs... That’s a quite good distinction, don’t you think?", maybe for a cymraeg speaker it is :)

[Profpatsch]

nixexprs

Pronounced “nix expressions” of course.

[trusktr]

nixpr --> nixpressions :+1:

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix42b-user-friendly-interface-for-the-nix-package-manager/5377/6

[nrdxp]

nxl → Nix eXpression Language