Nickel: Cheap Configuration Language

https://github.com/tweag/nickel

by lelf • 5 years ago

52 36 5 years ago

github.com

dang• 5 years ago

Related recentish thread:

Nickel: Better Configuration for Less - https://news.ycombinator.com/item?id=24858456 - Oct 2020 (60 comments)

neolog2• 5 years ago

Why do I want Turing completeness and general functions in my config language?

SAI_Peregrinus• 5 years ago

People like to write entire plugin systems in their config languages. This tends to be a bad idea in my experience, but there's a steady demand for it.

toolslive2• 5 years ago

why not use python as the configuration language then ?

layer82• 5 years ago

As soon as you add some kind of macro system or any other content-rewriting, template-with-parameters or functional-abstraction mechanism, you may as well go full Turing. Otherwise people will try to simulate it using the available mechanisms, as they have for example with the C preprocessor, resulting in higher complexity than if you’d just given them Turing completeness in the first place.

So the only real choices seem to be either a pure data format or else full Turing completeness. There doesn’t seem to be a useful middle ground, unfortunately.

kiwidrew2• 5 years ago

sendmail.cf was a warning, not an example!

fiddlerwoaroof2• 5 years ago

I think Dhall is an interesting point in this design space: powerful enough to write real functions, not Turing complete so all Dhall programs can be reduced to a normal form and compared for equivalence.

Doji5• 5 years ago

https://github.com/tweag/nickel#use-cases

neolog2• 5 years ago

Those use cases don't require those features.

resonantjacket5• 5 years ago

in general when you don't have it you end up with a mess of nested if statements. Or end up calling some outside script to inject some form of a function. Plus even without turing completeness you can still end up with exponential complexity.

longcommonname• 5 years ago

Sre workbook page 317.

solidsnack9000• 5 years ago

It would be interesting to see some examples of actual configuration. At present, the examples seem to be limited to type definitions, nested let bindings and things like that.

https://github.com/tweag/nickel/tree/master/src/examples

no_wizard2• 5 years ago

Is configuration really so complex nowadays that we need entire languages (DSLs, really) for managing them?

Isn't there a better way? I feel like its so 'popular' to provide config hooks into libraries and systems, rather than exposing a Programmatic API that's at least unit testable to understand the results you get back, which makes it infinitely more reliable, IMO.

APIs are harder, I realize, because it forces you to really think about what you're going to expose and how before hand, rather than perhaps after the fact.

I also realize the tradeoff is that configs are suppose to be more limited by design (you can only express so much logic even when using some of these complex templating systems, they all reach some finite point of complexity). They're also suppose to be more portable (configs don't require runtimes per say, though that looks like its about to change!)

Arguably however, its gotten so complex to manage configurations that I would rather just have exposed APIs for systems so I can have better, robust testing in a language.

I realize this means some systems will no longer be language independent, but when I can use an API instead, I almost always do. Configuration management has just gotten out of control.

To think, people say webpack is 'config hell'. Ever try dealing with a complex templated Kubernetes config? Saltstack YAML Jinja2 madness?

I'll take webpack any day. At least its typed!

/rant

With that said, this looks neat. I can also stand by the idea that if there is a sane way to create a DSL like this that exports to any reasonable format (json, ini, properties file, YAML) then that actually, I will completely concede, may be worth it.

rtpg• 5 years ago

You can either have a configuration bit which is like "add_two_to_every_result: true", or you can have "result_post_processing = function(x) {return x + 2;}".

When working on complex systems, I know which thing is going to be easier to use for my "bespoke" systems, and which one is going to devolve into spaghetti messes. Unfortunately I think loads of system have gone for the former.

I think that stuff like grunt ended up being a mess because it tried to straddle the two, and webpack has made stuff cleaner in that respect, by accepting computation.

Almost every build system in the world, however, really doesn't like this model. The first CI system whose configuration file is, like, Lua, will become a billion dollar business overnight.

Special frustration goes to Bazel, which gives itself a cliff-shaped learning curve out of its "we really don't want to run arbitrary code" feeling, while actually having all the moving parts. You just need to dig through a bunch of "really really please don't do this" stuff to find the real docs.

randallsquared• 5 years ago

You can either have a configuration bit which is like "add_two_to_every_result: true", or you can have "result_post_processing = function(x) {return x + 2;}".

In this case there's an intermediate "increment_result_by: 2" that would be better than either. Once in a while there are use cases that are so undefined that "do whatever you want" makes sense, but usually this is an excuse to not think too much about what the user wants to do, and why.

The benefit of both of the limited solutions over the other is that it's possible to fully test the entire space of configurations. it definitely is possible to let this style of config devolve into spaghetti, but at least there's some hope of untangling it in the future, which is much less possible if you accepted essentially any result transformation some enterprising user had spent a week programming.

If the right solution for configuring your system is a full programming language, consider distributing your system as a library or framework, rather than a system that needs "configuration". If your library is fully tested and someone screws up in their own code, that's a different kind of problem than if someone provides a syntactically correct config that causes your system to fail. Blurring the lines between these kinds of problems is not going to make supporting your (non-programmer) users easier, in most cases.

mdaniel• 5 years ago

The first CI system whose configuration file is, like, Lua, will become a billion dollar business overnight.

Jenkinsfile is written in Groovy and is not a billion dollar business that I'm aware of. Were you trying to emphasize the lua part?

Space from JetBrains has its build config written in Kotlin, for a more strongly typed version:

https://www.jetbrains.com/help/space/automation-getting-star...

I believe there are others but those are the two I have handy

shirro• 5 years ago

I feel like Lua solved this problem a long time ago and did it with a language fast enough for game logic and easy enough for children to learn. Although the s-expr people would justifiably argue scheme/lisp solved it much earlier.

kiwidrew2• 5 years ago

Tcl is another contender for a configuration language that has been around for ages and ages. Although it's not as slick as Lua, which was of course originally designed as an extensible configuration language.

gregwebs• 5 years ago

It’s nice to see a project that explains how it fits in the design space. Still after looking at this I get the feeling they haven’t really tried Cue in anger. I also think cue should be easier to introduce to a team precisely because it is restricted.

engineer331• 5 years ago

Not to be confused with Nickle, the numeric programming language.

http://nickle.org/

Nickel: Cheap Configuration Language

Related Stories