[throwaway894345]

JSON and YAML don’t offer any abstraction. If you want to describe kubernetes resources in such a way that you can deploy the same resources to many environments with subtle differences between them (e.g., namespace names, DNS names, etc) you want something to let you abstract so you aren’t manually trying to keep disparate copies of thousands of lines of frequently-changing config in sync.

The reason you don’t use regular languages for this task is because you want to enforce termination (programs can’t run forever without halting, allowing someone to DoS your system) or reproducibility (the config program doesn’t evaluate to different JSON depending on some outside state because the program did I/O). If your use case involves users who can be trusted not to violate these principles, then a standard programming language can work fine, but this frequently isn’t the case.

[cogman10]

> you want to enforce termination

Nickel is turing complete. See, the fib example.

> or reproducibility

Nickel doesn't force reproducibility

So again, why Nickel and not a GP programming language?

[aidenn0]

Sorry, my reply, like throwaway's missed the main point of your original comment of "why not a GP programming language"

A configuration file is uniquely suited to a pure and lazy language.

Pure, because the all the advantages of a pure language remain, while none of the downsides; the result of evaluating the function is your configuration data. You don't need to do arbitrary I/O and ordering for generating configuration files.

Lazy because configuration files are naturally declarative, but you don't want to evaluate tons of things you have declared but then never used.

[throwaway894345]

> Nickel is turing complete. See, the fib example.

I should have been more clear, I was listing potential reasons why you might not use a standard programming language. "Not wanting turing completeness" is a reason to use a non-turing-complete DSL. I wasn't suggesting that Nickel was appropriate for this particular use case, but many of the other languages in this category are (e.g., Starlark, Dhall).

> Nickel doesn't force reproducibility

Scanning the docs, I don't see anything about Nickel allowing I/O, so I believe you're mistaken.

[cogman10]

https://github.com/tweag/nickel/blob/master/RATIONALE.md

> However, sometimes the situation does not fit in a rigid framework: as for Turing-completeness, there may be cases which mandates side-effects. An example is when writing Terraform configurations, some external values (an IP) used somewhere in the configuration may only be known once another part of the configuration has been evaluated and executed (deploying machines, in this context). Reading this IP is a side-effect, even if not called so in Terraform's terminology.

[throwaway894345]

This is the relevant passage:

> Nickel permits side-effects, but they are heavily constrained: they must be commutative, a property which makes them not hurting parallelizability. They are extensible, meaning that third-party may define new effects and implement externally the associated effect handlers in order to customize Nickel for specific use-cases.

This answers your question about why Nickel is preferable to general purpose programming languages--the side-effects are more limited. Further, it reads to me like the "side-effects" are something that the owner of the runtime opts into by extending the sandbox with callables that can do side-effects as opposed to untrusted code being able to perform side-effects in any Nickel sandbox.

[yagoham]

Hi, blog post author here. The idea behind effects in Nickel is to have very limited, use-case specific effects that can extend the standard interpreter. The goal is, as the example suggest, to make it able to interoperate with an external tool when absolutely necessary, such as Terraform or Nix. The idea is really not to have general effectful functions such as readFile or launchMissiles.

[throwaway894345]

It's not clear from the docs whether any Nickel program can perform side-effects or if the Nickel interpreter must be extended to allow programs to perform side-effects (a la Starlark). Can you clarify this point?

[yagoham]

The Nickel interpreter is intended to offer a mechanism to make it possible to extend it to add "effects", which is really just a pompous name for an external call. The idea is that, if you want to integrate it with Terraform for example, you would want to have a "getIp" effect to retrieve the IP of a machine once it has been evaluated. So you implement your external handler (say in Rust or whatever), and then you can call "getIp" from a Nickel program. Currently, we see no reason Nickel would ship with any effect by default. These are really just for extension purpose. Such additional effects would be required to be commutative in order not to hurt parallelizability, but you can't enforce that mechanically, so you'll have to trust the implementer.