Hacker News Reader

Comment by codedokode | Hacker News Reader

While Nix's concepts are awesome, the implementation doesn't look so nice. Their "language" for writing Nix files [1] doesn't look attractive. Doesn't make me want to write a package description.

Of course, it is better than languages with lots of brackets, but still not good enough.

[1] https://github.com/edolstra/nixpkgs/blob/release-19.03/flake...

View on HN

For basic package descriptions, the language is not terribly different from JSON. Here's a definition of a Python application I'm working on:

    { pkgs ? import <nixpkgs> {}}:
    
    with pkgs;
    
    python3Packages.buildPythonApplication rec {
      name = "quicktill";
    
      src = ./.;
    
      doCheck = false;
    
      propagatedBuildInputs = with python3Packages; [
        dateutil pyyaml
        sqlalchemy psycopg2
        pycups reportlab
        requests_oauthlib
        pygobject3
      ];
    
      nativeBuildInputs = [ wrapGAppsHook ];
      buildInputs = [ gobjectIntrospection gtk3 ];
    }

The only big things here are the fact that this is defined as a function that takes the package repository as an argument to access dependencies (the first line), and the "with" expressions that allow me to skip having to type "pkgs." and "pkgs.python3Packages." for every package I depend on.

That looks completely inscrutable to me. Like a sequence of magic words. I don't see the connection with JSON at all.

I'm not really sure what you're finding inscrutable. I'll tear out the boilerplate that explains that this file is a function and returns a Python application (which is documented in the nixpkgs manual and can just be copy-pasted if you really don't want to figure out what it does):

    rec {
      name = "quicktill";
    
      src = ./.;
    
      doCheck = false;
    
      propagatedBuildInputs = with python3Packages; [
        dateutil pyyaml
        sqlalchemy psycopg2
        pycups reportlab
        requests_oauthlib
        pygobject3
      ];
    
      nativeBuildInputs = [ wrapGAppsHook ];
      buildInputs = [ gobjectIntrospection gtk3 ];
    }

Is that any better? It looks an awful lot like some dialect of something JSON-like to me - there's some different symbols used and array values are separated with spaces rather than commas, but aside from that it's just a record of key-value pairs.

From there, the first line in the original example says "the following expression is a function that is called with this parameter", and the parameter is an object containing a key called "pkgs", which is defaulted to the result of "import <nixpkgs> {}". This is explained in more detail in a handful of lines in the language manual.

Functions are called just by referencing the function and then the arguments separated with spaces, like Ruby or Haskell - so python3Packages.buildPythonApplication is a function that is called with the object above.

Finally, "with foo;" just means "every key in foo can be accessed without typing foo. in the next expression".

The result is basically: this file defines a function which takes an object containing the package repository as the "pkgs" key, and returns the result of calling pkgs.python3Packages.buildPythonApplication with the object defined in the rest of the file.

It's a lot more derived from the syntax of functional languages than C-like ones, but that's not necessarily a bad thing. Also: this is basically the entire language. There's a couple of different string syntaxes and some stuff for merging objects together, and also a mechanism for temporarily naming things that aren't part of an object, but in general... there's not a lot more to it. Most of the complexity is in the domain itself - what's the difference between a propagated, native and regular build input, how do you manage plugins and options for a package, etc.

What's your preferred packaging DSL?

I mostly deal with openembedded at work and I have few positive things to say about it. I'm sure Nix is much faster and nicer. Frankly it's hard to imagine that the opposite could be true.

But your example looks nothing like Json.

I'm not sure what to say. Replace the = signs with colons, the semicolons with commas, stick commas between array elements and stick everything between quotes and you basically have json.

That looks like a Turing-complete DSL. Not like JSON at all. Do we need yet another Turing-complete language for writing package metadata?

The example lacks functions / flow-control statements (ok, apart from "import if not defined", but it's more of a default value than a branch) / references to other elements. It's pretty much key-value dictionary. Not sure how you got an impression of Turing-complete DSL from that, since it would require at least one of them.

The Nix expression language has branches and functions (including recursive functions). It is Turing complete, and it probably is necessary for its charter.

OP said it "looks like" a Turing complete DSL just from the example. Regardless of what extra functionality the actually is, the examples didn't suggest it.

I guess I was giving the benefit of the doubt, since that's such an irrelevant nit to pick...

It's not "package metadata", it's the complete instructions for building an entire operating system in an automated way.

The complicated bits are the import notations (what do the different variations mean and when to use them?), the recursive declarations (and knowing when to use them). Also, since expressions are often functions and the nixpkgs people don’t believe in types or docs, it’s difficult to track down the type info for each argument (what properties does it have?). You just end up grepping blindly through nixpkgs to find the callsite and even then the argument is often the result of a function call, so you have to find the function and it’s definition and look at the return and hope that it is not “return someOtherFunc()” lest you have to track down yet another function (also, odds are “someOtherFunc” is not the name of the function, but rather the name of a parameter into which a function was passed, so you’re back to blindly grepping nixpkgs).

Nix is great in concept but the language or idioms make it really difficult to use.

By the way, there is a list of dependencies, but no version numbers. Is that ok? Even if in theory packages should be backward-compatible, it doesn't work in practice.

Regarding syntax, I would prefer something like this:

DEPENDS_ON python 3.5.1, python/dateutil 1.2.3, ...

BUILD_TOOL bash 1.2.3

BUILD_SCRIPT ./build.sh

This works fine in Nix because those package names are the names of derivations that themselves pin a given version of said packages.

In practice, the default set is expected to be somewhat internally consistent, so that you can just use the package names to refer to the "most recent consistent set". But if need arises, you can also override individual packages to pin them at a different version than the upstream-provided one.

Sounds like you wouldn’t like GuixSD either.

Well you might be right, but I find Nix and NixOS to be great. Honestly the language isn’t the issue, it’s just that it isn’t nearly as well supported as more popular distros like Ubuntu, so for example my VMWare Workstation license has been sitting dormant for a while now... (Which is mostly OK. I’ve been using libvirt for everything and pleasantly surprised at what it can do.)

The language takes some getting used to, and I am not really 100% sold on pure functional, but it works and my systems are much more reliable now.

But since when a language need to looks attractive?

First of all, "attractive" is simply your way to say "familiar to me".

Then, a language need to be just powerful enough to express it's semantic and no more.

This critique is quite hollow and noisy.

Even after writing substantial number of nix scripts and taking some weeks of break (because my job is not writing nix scripts 24/7), I struggle to remember all of that structure inheritance magic and have to reread the docs. Not a good sign, usually happens with me with unnecessarily overengineered things.

What do you mean by "structure inheritance magic"? I can't think of anything I'd term "magic" in the Nix language.

Nixpkgs itself does a lot of funky things, especially around overrides and whatnot, but those are features of Nixpkgs, not of Nix the language.

> Not a good sign, usually happens with me with unnecessarily overengineered things.

Haha yes, I mean clearly this means it's Nix's fault. Has anyone ever considered using you as some kind of "overengineering divining rod" where they can just wave something in front of your nose and go back to the drawing board if it doesn't pass?

There are various problems with nix and the pragmatics of the language (error reporting combined with lack of static type checking, inconsistent naming conventions, evaluation speed, tooling, etc.) – but the core language itself is, IMO, actually extremely well designed. I can think of very few good external DSLs (postscript is the only one that comes to mind right now) – but I'd definitely place nix among this list.

At least that language does not require quotes around almost every sequence of letters like JSON does.

(Yes, I know, JSON is not a language, but people do sometimes use it for things approximately as long and as complicated as a Nix expression.)

cough YAML cough

Oh, man, let's not go there. It's a silly place.

Somehow, right?

But why isn't there an ML with the good parts of YAML, but without the bad parts?

YAML (and TOML and even XML when it's being used in a tag-centric way instead of a text-centric way) are not markup languages. A markup language is one that allows you to assign meaningful annotations to regions within a chunk of textual content (e.g. "these three words are underlined", "this relates to footnote 3", etc.). YAML and TOML have both changed the meanings of their acronyms to try and distance themselves from their original misnamings as "markup languages".

Yep. Maven (ugh) even has switched off entity expansion, a basic feature of XML/SGML, in favour of their own ad-hoc ${property} syntax.

Anyway, the GP's question is a good one. Where are the configuration/serialization languages that import the only good parts of YAML?

AFAIK, one can not subset YAML and get something coherent. But one can start from scratch and use its concepts. I imagine the languages are not there just because nobody got the time to do them.

The nix language is a bit hinky; unfortunately nothing available even approaches it in terms of capabilities.

I ran Nix for about six months. The language was one of the factors that really bugged me at the time. That and the hoops you had to jump through to do basic things like installing npm packages...

Reply on news.ycombinator.com