A tale of Nix and Nickel
Please log in to watch this conference skillscast.
What do package management and functional programming have in common? More than it seems!
In this talk, I will introduce the Nix package manager, which applies principles from functional programming to overcome fundamental challenges of package management. It crucially relies on a functional programming language, also called Nix, of which I will discuss the current state and shortcomings. I will finish presenting our new configuration language Nickel which attempts to solve some of them.
Q&A
Question: What is the type inference like in Nickel, compared to Dhall? In particular, maintaining type annotations for [] or `None`s in Dhall is quite frustrating
Answer: It's an ML-like type inference, so like "boring" (that is, without fancy types) Haskell or OCaml. The difference is that it doesn't generalize for you: if you need a polymorphic type, you have to write it by yourself. But the type system is less powerful than Dhall, and the upside is that you don't have to annotate empty lists for example. Nickel doesn't have sum types yet though, because it is surprisingly non trivial to design well with the gradual typing and contracts part. Well I forgot one important thing, Nickel has row types (or structural typing for records), and type inference for it, which can be helpful when handling JSON-like data.
Question: What is your opinion on the Guix project?
Answer: I've not used Guix extensively, but it is also a good solution. It is based on the same underlying principles as Nix, and solves more or less the same problems. It is younger (2013 vs 2006 for Nix) so it made different choices: for example, it uses Scheme as a language to describe packages (which is better in some sense than current Nix, because the language does the same but is more widespread, comes with mature tooling, and so on, but it also doesn't solve the typing/abstraction problem).
All in all, with the privilege of hindsight, some parts are maybe more consistent than Nix. On the other hand, it is less mature: the package set and the community are smaller, the resources are even scarcer than for Nix, and so on. Maybe try both and see what fits you.
if you're interested about trustability, check out Trustix: https://www.tweag.io/blog/2020-12-16-trustix-announcement/
Question: Is the Nix project interested in adopting Nickel in Nixpkgs any time soon?
Answer: Well, we first have to get this first release out and convince people that it does solve part of problems. Changing the language is not a small change. But I hope it will happen at some point
Question: or adding similar gradual typing to nix itself?
Answer: To be honest, Nickel is not very far from that. Notwithstanding syntax, it is close to being a super of Nix (although it is currently not exactly the case). The problem is that Nix syntax is kinda idiosyncratic: using : for function parameters would prevent from using it for type annotations, for example. This is not awful but all of these little things add up. Granted, syntax compatibility is still important, because that means you can't just add types to an existing Nix code-base seamlessly.
Question: Is there an alternative approach to nixpkgs and learning to structure nix projects other than reading the source and trying oneself? Like, is there a Gang of Four of Nix book?
Answer: Yes, there is the Nix Pills series indeed: https://nixos.org/guides/nix-pills/. But beginner friendly documentation and tutorials are clearly missing, that's a big issue for adoption unfortunately, that we try to work on.
The links from the last slide:
Nickel repo: https://github.com/tweag/nickel/
Our blog: https://www.tweag.io/blog/
My mail: yann.hamdaoui@tweag.io
YOU MAY ALSO LIKE:
Thank you to our sponsors and partners
Platinum
Silver
Bronze
A tale of Nix and Nickel
Yann Hamdaoui
Software Engineer
Tweag I/O