Alternative language

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

3 Likes

Yep that’s the one. See * Drop the dependency on the ATerm library. · NixOS/nix@f3b8833 · GitHub

3 Likes

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.

14 Likes

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.

3 Likes

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.

3 Likes

@edolstra do you mind rehashing here the part in that talk about the alternatives - slide 17? (also for posterity’s sake :grimacing:)

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.

2 Likes

what do you mean rehashing? He expanded on his sentiment in another post

1 Like

…which is the post that I replied to :slight_smile:

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

2 Likes

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.

6 Likes

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.

2 Likes

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.”

4 Likes

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/

2 Likes

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 :slight_smile:

1 Like

Looks quite useful thanks for sharing, greater visibility for the existing docs is nice to have.

related: GitHub - tweag/nickel: Better configuration for less

3 Likes

I am excited by the idea of using TOML.

Appearently this has been around for quite some time, but has never really taken off.

There is a thread that is also showing an interesting way, how Idris does source TOML files, but there has never been any further comment on it.

I think TOML is far more readable, and could particulary draw in people from Rust, Python and other communities, where it is popular, or even the default choice.

It could remove the long standing issue, of people being scared of Nix as a language.

You could use TOML already with just a little generic code using the builtins.fromTOML function.

This would work fine with any pure value options but not for options that require the use of functions or derivations as neither of those exist in TOML. They’re quite essential for the purposes of NixOS though, so I don’t think you’d get very far with a TOML-only config.

5 Likes