Nickel 1.0 release

[yannham]

Dear Nix community, we are happy to announce the 1.0 release of Nickel, a configuration language we are developing at Tweag. As some of you may know, Nickel was born as an attempt to fix a number of shortcomings of the Nix language, but has evolved as an independent, standalone configuration language that can evaluate JSON, TOML and YAML. You can read the 1.0 announcement on our blog.

What does it mean for Nix users? This release is mainly about the Nickel core language itself, but other Tweagers are putting Nickel to use by designing the easy-to-use, easy-to-customize Nixel development shell framework on top of Nix with Nickel as a front-end language. The core language and Nixel are co-evolving: we hope the 1.0 release lays out a solid ground on which Nixel can develop faster!

[mightyiam]

I was looking forward to this. Thank you for working on this. And thank you, Tweag, for sponsoring.

[bjth]

Congratulations!

I hope to see Nickel everywhere now. Terraform HCL, Nickel. Pulumi, Nickel. Nix, Nickel.

[Sandro]

Standards

Also you should consider adding syntax highlighting to GitHub - github-linguist/linguist: Language Savant. If your repository's language is being reported incorrectly, send us a pull request!

[yannham]

We considered adding Nickel to GitHub linguist, but there is a condition for adding a new language, namely that 200 unique repositories use the file extension (linguist/CONTRIBUTING.md at e1c3110a4429d79deba370ceefda372dad03b003 · github-linguist/linguist · GitHub). It wasn’t met last time we looked

As for the XKCD meme, I know it is meant as a joke, but I don’t think it totally fits the situation. There are not many competing standards, but mostly one, which is the Nix language. Although one could argue that because it is bare-bones people are developing DSLs as librairies (NixOS modules, Nixpkgs, std flakes, etc.), which could be those competing standards. At least in the Nix space, I see Nickel more as a proposal for an evolution and an upgrade, than a language competing at the same level. I would personally see it as a success as well if some of the Nickel ideas make their way in the current Nix language, without really switching to Nickel!

Fact is, because we use those totally dynamic DSLs embedded in Nix, without any standardization precisely, my personal experience is that developing Nix expressions feels decades away from my experience in the other languages I use on a regular basis (I’m thinking LSP and error reporting in particular). I hope this doesn’t come as a criticism: as an open source maintainer I know how much time, effort and people it takes to do things the right way. On the contrary, I find it really impressive that Eelco, and more people lately, have developed both a language, a package manager and an OS all at once with so few resources. Still, one of my first experience with NixOS was an infinite recursion error pointing to internal Nix code because I misspelled a function argument.

It is undeniable that any new shiny thing comes with a risk of fragmentation (hello, flakes ), but I sometimes I think the risk is worth it (otherwise, nothing ever improves). People will have differing opinions on when it is the case, though. With respect to Nixel, it is also meant as a driver for Nix-Nickel interaction, but we’ve already started to talk with @domenkozar about e.g. devenv.sh and if and how there could any kind of co-operation: the goal is really not to do yet another developer environment framework on our side, but we also need to have a working demo first before people can decide if Nickel is a useful tool or not

[matklad]

The there last sections of the docs, about types and contracts, are delightful:

https://nickel-lang.org/user-manual/typing

I was always skeptical about design-by-contract programming languages/DSLs, as there’s seemingly very little useful space left between types and assertions. But Nickel’s confluence of contracts, gradual types, and laziness is a fantastic mix! Learned a bunch of new today, thanks!

[yannham]

@matklad

I was always skeptical about design-by-contract programming languages/DSLs, as there’s seemingly very little useful space left between types and assertions. But Nickel’s confluence of contracts, gradual types, and laziness is a fantastic mix! Learned a bunch of new today, thanks!

Thank you

In the end I think even the peope who’ve been taking part in the design of Nickel feel a bit the same: we ended up with several non-mainstream features that weren’t in our default toolbox, because those features did seem to be a great solution to the design goals and constraints we had. I’m not sure such things would work so well in e.g. a general-purpose language. The design space of configuration languages seems to be quite unique, which makes it so interesting!

[UefiPls]

I heard about this some time ago and the people talking about it were excited about static typing.

My questions are:

• how does debugging work? is there a debugger with breakpoints?
• how does this fit in with nix-lang? the examples don’t seem to generate nix scripts nor does it seem possible to import nix scripts

I would love to replace nix scripts with nickel if debugging were easy (or even possible at all). As a newbie, I haven’t found a way to do so with nix besides just reading stack traces and those are difficult to read. Errors can occur very deep in within nixpkgs and for some reason it can even mess with the stack to make it seem like the error is in another place of the script.
The lack of a debugger certainly doesn’t help either.

[yannham]

There is currently no debugger with breakpoints (not yet! this is surely an item on the roadmap). This is indeed important, as the whole point of all the (fancy?) features of Nickel isn’t to align buzzwords on the website but is precisely to improve the developing and debugging experience (not only, but I would dare to say it’s the main point).

What you describe (errors occurring deep inside Nixpkgs) is a general problem with pure dynamic typing (see the very good blog post of Gabriella Gonzalez, dynamic type errors lack relevance). I think that is where static typing AND contracts can help. The static typing + contracts approach is also motivated in the correctness section of the Nicke user manual. So, this dynamic type errors issue is mitigated by language-level features in Nickel. This doesn’t fully replace a debugger, though.

With respect to Nix, the longer term plan is to be able to use Nickel as an alternative front-end language for Nix (to write packages, flakes and modules), with the ability to still evaluate and leverage existing Nix code. The corresponding Nickel RFC is drafted here. Simply piggy backing on Nixpkgs won’t make the error better at first, I reckon. But the advantage of gradual typing and contracts is that we can incrementally refine this interface (and/or migrate packages to pure Nickel) to get better and better error messages. We’re not there yet, though.

The most concrete work to this day is Nixel, which is focusing on writing devshells (where we think Nickel could really help with composability and overriding, while requiring a smaller and better scoped effort). It’s currently working but rough, officially unreleased, but it’s probably going to reach 0.1 soonish (although I’m not overseeing this effort as much, so I prefer to ask people who’ve been more active recently on this front such as @regnat ?)