yees, string context is quite interesting concept.
Also, lazy+scripty+dynamic typing is fun enough to try it out. I know Lisps can be whatever lazy they want, but I doubt this feature is used (compared to Nix).
I think this particular case (overlays and overrides) is solved by classes and virtual functions.
Nix package manager isn’t restricted to Nix language. Guix uses Nix under the hood but all the expressions are in Guile.
Nix has an intermediate, compiled expressions called .drv files. It is no longer in Nix language, it is Python language!
In [1]: class Derive:
...: def __init__(self, *args): self.derivation = args
...:
In [2]: from pprint import pprint
In [3]: def readDrv(drv): return eval(open(drv).read()).derivation
In [4]: pprint(readDrv('/nix/store/gmxsxf5gbipxwhl8s35jzqz2xgvkfpz2-hello-2.10.drv'))
([('out', '/nix/store/234v87nsmj70i1592h713i6xidfkqyjw-hello-2.10', '', '')],
[('/nix/store/1p7mib5jjp6kqij706y2j6pjmadhx5ly-stdenv-linux.drv', ['out']),
('/nix/store/b3x96w1hy6sxlxk1a1i5fd24b4z6xvv0-hello-2.10.tar.gz.drv',
['out']),
('/nix/store/ij7yr26mjpnpj78min707x88cbg35sl8-bash-4.4-p23.drv', ['out'])],
['/nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25b-default-builder.sh'],
'x86_64-linux',
'/nix/store/xb062l4b76zyhq6grqf4iyfdikkpg8fl-bash-4.4-p23/bin/bash',
['-e', '/nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25b-default-builder.sh'],
[('buildInputs', ''),
('builder',
'/nix/store/xb062l4b76zyhq6grqf4iyfdikkpg8fl-bash-4.4-p23/bin/bash'),
('configureFlags', ''),
('depsBuildBuild', ''),
('depsBuildBuildPropagated', ''),
('depsBuildTarget', ''),
('depsBuildTargetPropagated', ''),
('depsHostHost', ''),
('depsHostHostPropagated', ''),
('depsTargetTarget', ''),
('depsTargetTargetPropagated', ''),
('doCheck', '1'),
('doInstallCheck', ''),
('name', 'hello-2.10'),
('nativeBuildInputs', ''),
('out', '/nix/store/234v87nsmj70i1592h713i6xidfkqyjw-hello-2.10'),
('outputs', 'out'),
('patches', ''),
('pname', 'hello'),
('propagatedBuildInputs', ''),
('propagatedNativeBuildInputs', ''),
('src', '/nix/store/3x7dwzq014bblazs7kq20p9hyzz0qh8g-hello-2.10.tar.gz'),
('stdenv', '/nix/store/cis5rcj9qvm94wq7ch500jnszshc3wx8-stdenv-linux'),
('strictDeps', ''),
('system', 'x86_64-linux'),
('version', '2.10')])
I can testify, since I tried Guix before Nix, that the language learning curve was even steeper. However, the main motive for me to try Nix instead wasn’t the language but the community 
.
Nice trick! This is actually a happy coincidence. The .drv files are written in an obscure academic language called “aterm”. It was selected by Eelco because it makes some guarantees in terms of reproducible output like ordering the keys alphabetically.
Nowadays most references to it have disappeared in the nix code. The upstream library has been merged into the nix code base and upstream has disappeared.
Nice trick! This is actually a happy coincidence. The .drv files are written in an obscure academic language called “aterm”. It was selected by Eelco because it makes some guarantees in terms of reproducible output like ordering the keys alphabetically.
Nowadays most references to it have disappeared in the nix code. The upstream library has been merged into the nix code base and upstream has disappeared.
Wow, I didn’t expect that. This is quite interesting! TIL
Is this the aterm language you mentioned?
http://www.meta-environment.org/doc/books/technology/aterm-guide/aterm-guide.pdf
Yep that’s the one. See * Drop the dependency on the ATerm library. · NixOS/nix@f3b8833 · GitHub
I gave a (rambling) talk on the Nix DSL a couple of weeks ago: https://nixos.org/~eelco/talks/build-systems-nov-2019.pdf
TLDR: the Nix language has all the problems of a general purpose language (namely too much expressiveness, allowing people to build new abstractions that make it harder for other people to understand their code, and making evaluation slow), while not having the features you would expect from a general purpose language, and at the same time not having many domain-specific features (indeed string contexts are one of the few). So it’s not that great as a DSL or a GPL.
I gave a (rambling) talk on the Nix DSL a couple of weeks ago: https://nixos.org/~eelco/talks/build-systems-nov-2019.pdf
Are there recordings of the symposium? I couldn’t find any reference to
it by searching online.
No, I don’t think it was recorded.
I’ve been off computers for a while but if there were an inherit (x) a b equivalent for arrays, and with were eliminated, nix as a language would be extremely small and reasonably consistent and easy to read. I would blame with keyword for most of nix’s problems.
@edolstra do you mind rehashing here the part in that talk about the alternatives - slide 17? (also for posterity’s sake 
)
I think it’s useful to have an explicit discussion about what is it that the alternatives cannot express that’s required for the Nix use case.
what do you mean rehashing? He expanded on his sentiment in another post
…which is the post that I replied to 
I’m assuming that more was said in the talk covering the alternatives than what’s in the slide, and was hoping to have it written here in context of the alternatives discussion
Especially interesting are the cases that are core to the Nix use case but other configuration languages are not expressive enough to cover
There’s a good podcast at https://www.youtube.com/watch?v=JKJTfrGNMPY covering the topic of configuration languages. There’s a lot of similarities between dhall and nix-lang.
I actually quite like Nix (lang), I think it’s really specialized for doing package configuration, but it fits the role really well without few oddities.
As a beginner to nix language, to me the most frustrating aspect of it has been the complete lack of tooling around nix, unlike other real languages there is no autocomplete, no documentation on hover, nothing that tells me what arguments this function takes, no goto definition and so on.
I’m not sure if this lack of tooling is related to the way the language is designed internally that makes it harder for such tools to exist.
I did watch a recent nix con talk on improving nix ergonomics with modules and I’m optimistic about that.
An alternative language that inherits this lack of tooling and documentation while merely providing a more common syntax won’t provide much benefit I suppose.
these things are harder to implement with functional programming languages. OOP languages have the benefit of having all the classes, methods, fields, and properties known ahead of time.
In functional programming you’ll say something like:
valid_values = filter (x: x.is_valid) all_values;
It’s hard to know what you were meaning to type. Some languages have “type holes”, but generally you still need to write the majority of the expression, and leave only one “hole” open. Unfortunately, nix doesn’t have this as it’s dynamically typed.
But in general, I agree, I had to “cut my teeth” by looking at other code within nixpkgs. And the IDE experience isn’t great. I just use vim + coc + vim-nix. But, I generally have to know ahead of time, the code I need to write.
In defense of functional programming, it takes me a bit longer to get started because I have to learn the “prelude” of functions that are commonly used. The most common functions (map, fold, filter, etc) usually carry over between languages, so if you’re familiar with another functional programming language, then learning this is pretty quick.
(rant warning)
Another benefit of functional programming is that I don’t usually experience, “I need to do X, and class Y looks like the right class. Let me learn how this one class is defined, and it’s very similar to this other class Z; but since it needs to differ in this one regard, it should be it’s own class. Oh, and since class Z was sealed, this makes sense why they didn’t make class Y a subclass of Z; but now it uses slightly different conventions so it’s similar but not the same now. Oh, and I forgot that this class’s parent-parent-parent-class already implements this, and I should have just done that.”
Nix-lang is a Domain-Specific-Language. It’s not a general purpose.
Most of the information you’re looking for is probably implemented in nixpkgs, and not in nix-lang. Nix-lang really only offers the core datatypes, keywords and related programming constructs, operators, and items under builtins. Everything else is implemented within nixpkgs.
I see so you are saying nix lang has no standard way of defining function documentation, module documentation and so. The way I see it is nixpkgs defines many of the library functions that are helpful to build packages in different languages but these are undocumented often and short of reading their usage or source its hard to understand how to use them
you will also likely be interested in nixdoc package.
As well nix-doc https://www.reddit.com/r/NixOS/comments/i4pnsj/nixdoc_a_nix_function_documentation_search_tool/
module documentation is auto generated, if on nixos, you just do man configuration.nix for nixos options, man home-configuration.nix for home-manager. I’m assuming nixpkgs-darwin has something similar.
This is probably me being pedantic. But the lib functions, don’t know anything about derivations, they are only helpers around evaluating expressions. “functions that are helpful to build packages in different languages” are usually referred to as mkDerivation helpers, and they are usually documented here: Nixpkgs 23.11 manual | Nix & NixOS
Agreed, improvement to docs are always welcome