State of the Nickel in Nix ecosystem

1

I’m not a frequent user of Nix, it just works most of the time, but when I have to do something new - it feels I need to relearn the whole language and stdlib every time, I’ve never been a big fan of the lang. Then I got super excited when I first heard of Nickel development and from what I’ve got back then it incepted as a potential replacement for the Nix lang in the Nix ecosystem.

Today it seems Nickel has reached a stable version, has a lot of features and actively developed, but lives its own life independently from the Nix ecosystem. Are there any plans to blend it in or I misunderstood something? Is it possible at all, given how huge the nixpkgs repo? Are there any initiatives (in realm of nix-darwin or NixOS) that are standardized on Nickel?

2 Likes
2

I don’t think nickel will be able to be used in place of Nix any time soon. As such while Nickel is cool, it falls in the same realm of “cool but useless to me” as dhall and other such langiages.

For Nickel to be blended as you put it, into Nix, Nox the program would have to gain support for pluggable interpreters, which may happen one day. However that would not allows to call Nix from Nickel and vice versa, for that a much more technically challenging common ABI/API would be needed. Personally I doubt that’ll ever happen. We may get iterations on the Nix language using file local features flags or headers specifying “nix: 2.0” but I don’t see a future where nickel is able to coexist with Nix in single evaluation.

1 Like
3

Nickel has been “stable” for 3 years yet lacks some of the fundamental properties that make nix useful. So I imagine it will stay as an unrelated project for years to come. I’ve not encountered anyone trying to integrate nickel into nixpkgs or nixos.

Probably because you don’t use nix often or with any depth, so I suggest finding a project to work on if you really want to use nix.

1 Like
4

For clarity to less experienced readers: these are first class paths (you want to reference files to build your own software, wrapping Nix fetchers is already possible) and controlled side effects (those data structures need to eventually run as processes so the software gets built). Organist was a proof of concept that (IIUC) skips the side effects and generates a huge Nix expression to be evaluated as a whole, this works but isn’t very efficient.

2 Likes
5

I think maybe lazy imports is also an important missing feature in Nickel.

However that would not allows to call Nix from Nickel and vice versa, for that a much more technically challenging common ABI/API

Nickel does have an experimental feature allowing you to import and evaluate Nix. The interface is pretty limited, though: it evaluates the Nix code eagerly and treats the result as just plain data.

2 Likes
6

Nickel does have an experimental feature allowing you to import and evaluate Nix. The interface is pretty limited, though: it evaluates the Nix code eagerly and treats the result as just plain data.

While cool, its not useful beyond very specific cases. Nix would have to gain some kind of bytecode and then Nickel could compile to that. Though at that point it would be little more thwn syntactic sugar.

7

Hopefully at some point that could be a possibily (if I’m not mistaked you were experimenting with a STG for nix?). One data point that @roberth mentioned to me is the Lazy Virtual Machine by Daan Leijen, which is kind of academic abandonware, but still an example of a bytecode for lazy untyped languages.

1 Like
8

In theory, I think it could be possible to have a new program, which would be able to evaluate both nix and nickel language, allowing for a slow integration of nickel. I think snix has a bytecode interpreter evaluator (see overview).

In practice, I have no idea, I feel like we are still miles away.

9

Nix could get plugable evaluators someday, talked to @roberth about it already

Then yes, you could write a new evaluator, like snix did, or lile i was doing, which can eval both nickel and nix.

10

Yeah, i was doing STG but it wemt nowhere sadly. I got sidequested by other random things.

11

Probably because you don’t use nix often or with any depth, so I suggest finding a project to work on if you really want to use nix.

I personally think that this line of reasoning is a slippery slope, and could be applied to asm, C, etc. One typical problem of Nix is that, for most people (maybe not here but where we want Nix to succeed), Nix is the kind of language that you don’t use very often, like shell scripts. And it’s very poorly discoverable, at least in my personal experience with many other programming languages. I think the language, while a specific part and arguably small in the universe of room for improvements, still plays a role in everyday small cuts (debugging being another one). Whether they are better solutions out there is a different question, but there is something to be improved, IMHO.

Indeed the state of integration between Nix and Nickel hasn’t changed much in the last few years. Initially we set up to first lay out solid foundations for the core language, documentation, interpreter, and tooling. This is an ever-ending line of work, and is enough to have our plate full. Additionally, we want Nickel to be a universal and generic configuration language (there are people using it production for K8s resources and bunch of similar tools). This means that we avoid the introduction of Nix idiosyncratic concepts (derivation and in general effectful store actions, string contexts, paths), and try to find more generic subsuming notions that could be re-used in other contexts, but this makes the process slower and harder.

Another issue is that looking at the integration problem more closely, having a reasonable cross-language interface with Nixpkgs is quite hard technically, and is a big undertaking. There are light ways to use Nickel over a Nickel-blind Nix set-up in theory (like Organist, but not only), without needing Nix to know anything about it (see for example some ideas laid out in https://github.com/nickel-lang/nickel/pull/693). But ultimately I think that to really reap the benefits from a language shift, one would need a tighter integration, which is a mammoth task (putting aside the political aspect that it might need buy-in and changes to the Nix side).

We currently don’t have clear plans to dedicate a substantial amount of time to the Nix integration part, though we would be happy to support anyone trying to tackle the challenge.

@fricklerhandwerk by the way I’m curious about where your Nixcon experiment went, and if there are any interesting conclusions to draw to move things further?

3 Likes