Nixpkgs for the frontend impaired
10 points by tuxes
10 points by tuxes
Nix is lazy, so the emitted code wraps an expression in nix.thunk(() => ...) wherever Nix would allocate a thunk. š¤®
As per a post by Gabriella, it's not clear if nixpkgs even needs the full generality of the Nix language:
nobody actually uses Nix the language at any significant scale. Instead, the community has adopted two sub-languages embedded within Nix for programming āin the largeā:
- Nixpkgs overlays: This is an embedded language that simulates object-oriented programming with inheritance / late binding / dynamic scope (depending on how you think about it)
- NixOS modules: This is an embedded language that roughly emulates Terraform
How far is nixpkgs from being adapted to not need the Nix language, and instead be more... declarative (!), and permit more flexibility for consumers that want to benefit from this grand collection of packaging and modules.
Rough idea:
This is amusing to me, because the "full generality of the Nix language" emerges from one of the simplest languages possible: it is essentially JSON with functions and lazy-evaluation of object properties. That you can build languages like the NixOS module system (NMS) with this shouldn't be a surprise, because we build incredibly powerful languages on top of C all the time.
I think what Gabriella is getting at isn't that the Nix language is too powerful; it's that we have built towering, complex systems on top of this very simple language that doesn't provide the tooling and abstractions we typically need for towering, complex systems. I'm talking about things like types here; incidentally, a type system is one of the features included in NMS. I love that you used Jsonnet as an example here because there is nothing stopping us from writing towering, complex systems with Jsonnet functions, exactly as we do in Nix; the languages are not all that dissimilar.
Another language that re-implements this mistake is Starlark, used by the Bazel and Buck build systems. It also wants to forbid higher-level abstractions in the name of being "declarative", and using it is every bit as magical and bespoke as using nixpkgs, except somehow I can understand much of nixpkgs and grep the repo for the things I don't, while understanding Bazel and Buck still eludes me.
There is probably a name for this pattern in software development: the urge to encode everything as data, all the while inventing a programming language in your simple data format to handle every diverging use case. I think a good middle-ground is Nix flakes, where only the network dependencies are locked in a flat-file format, with the rest written in a structured Nix file.
There is probably a name for this pattern in software development: the urge to encode everything as data, all the while inventing a programming language in your simple data format to handle every diverging use case
I see the opposite urge at times too, and they're both part of exploring the design space.
The motivation is that NixOS/nixpkgs have performance/usability issues that could be more easily solved if the domain logic can be expressed in a simpler model. Whether it can is an open question.
There is probably a name for this pattern in software development: the urge to encode everything as data, all the while inventing a programming language in your simple data format to handle every diverging use case. I
In the meantime, the critical internal plumbing on Nixpkgs needs full power of Nix, implementation of modules (as in, Nginx module, not the module system core) needs much of the power of Nix, Nix got to be a full-powered language just by a happy coincidence, and it is implausible that a better layer would be designed and rolled out and be sufficient for the next big chunk of functionality.
it is implausible that a better layer would be designed and rolled out and be sufficient for the next big chunk of functionality
I'm hopeful we can do better. Some are exploring alternatives to modules:
Sure, at a library level there are better alternatives to modules (and no good one will be ever adopted by Nixpkgs), as they can be used in parallel with whatever mistakes get enshrined in mainline. I was talking that a better language layer won't happen.