nickel

-class language feature, there's been more emphasis on tooling than Nix had at comparable stages of its own development (including LSP support). I think it's a really interesting language. If its bet pans out, it'll stand out among configuration languages for offering a nice gradient of simplicity and sophistication, like Nix does: simple configs feel plainly readable, inert, and unceremonious, but you have enough power to offer clean interfaces if you're writing something that adds new features. But it promises to do it without the sharp edges Nix has. Time will tell! https://nickel-lang.org/ https://github.com/nickel-lang/nickel

of functional purity are pretty obvious, but writing code that you can't make sense of later is so much easier for me in functional languages. They're so powerful and elegant that writing nearly indecipherable things feels very tempting at times. So, I'd be interested in seeing someone attempt a Nix-like ecosystem built around something else. If Bazel can do "hermetic-ish" with Starlark, I reckon you could pull off something like Nix with it, too.

, and Elvish. Upstream distributes the tooling (which is, Go-style, a single executable with subcommands) as a Nix flake, a Docker image, and static executables for Linux aarch64 and x86_64 (< 30 MB, for now at least). Nickel doesn't yet have a package manager[3], but other than that it honestly has a better tooling story than many general-purpose programming languages currently in widespread use. CUE, an older (but not old) configuration language (very cool in its own right), likewise has great tooling. It ships with a command-line evaluator, a pretty printer, a formatter, package management based on Go modules (i.e., it has both a `mod` and a `get` subcommand), a few refactoring tools, and tab completions for bash, zsh, and fish.[4] It currently lacks a language server[5] but there is recent and ongoing work to enable that. There's no reason that a configuration language can't have first-rate tooling! There is a new crop of really innovative, powerful configuration languages out there. I hope they start catching on. > This way all your users are suitably placed on a slippery slope where one edit in the same language but to another file will transition them from user to contributor. > Jail them in a separate language and they'll stay users forever. This, I admit, deeply appeals to me. It's one of the things I really like about the Nix language, wart-y though it may be: the tools you use to configure your NixOS computer are the same ones you can go on to use to extend NixOS. I think that's an enormous strength. But I also like for simple configuration to look really simple, and not trouble you much with the details of the language (or, God forbid, configuring the runtime). Perhaps programmable configuration languages, then, are good fits for tools like build systems and packaging systems (where the 'upstream' code users might next want to play with is also essentially fancy, expressive configuration in a special domain), but embedded DSLs might be better for applications (and work for packaging and build systems, too). Re: creating a continuous road for users to hack on the software they use, GNU is really trying to do something special there: with Guix you have application configuration, package management, and system configuration handled in a DSL in Guile Scheme. But then Guix itself is also written in Guile! And at the same time, Guile is the official extension language of the GNU project, so GNU applications all (hopefully?) have Guile bindings, so you can use the same language to plug into (hopefully?) all the other GNU applications on your system. It's a cool idea. -- 1: https://github.com/tweag/nickel/pull/405 2: https://www.tweag.io/blog/2024-05-16-nickel-programmable-lsp... 3: https://github.com/tweag/nickel/issues/1585 4: https://cuelang.org/docs/reference/command/ 5: https://github.com/cue-lang/cue/issues/142

d. I think the recent development around json-schema-to-nickel and the availability of JSON schemas for NixOS modules (as mentioned at the end of the post) might make it realistic to write boring NixOS configs in Nickel (and have the nice in-LSP validation), but we haven't had the time to try this combination yet.

eing purely functional in turn underlies the congruence of the NixOS operating system, where you declare what the state the system should be in (as opposed to being convergent, so that you specify how to achieve the desired state). 3. lazily evaluated: similar to other build systems (including Bazel), so that you can build only what you need on demand. 4. dynamically typed: this one is controversial. Being dynamically typed—in other words, not developing a type system—gets Nix out of the door 20 years ago. But users often complain about the lack of proper types and modularity. There are experiments to add a type-and-contract system to Nix, such as Nickel (https://github.com/tweag/nickel). Most of the above are also listed in the Overview of the One Pager.