A reasonable configuration language

The problem isnt "configuration"

Yaml, JSON, xml, text files... all work great for configuration.

But the assumption is that your configuring a piece of software on an already existing system.

A config file as means of setting up a system, installing software, and establishing how its going to run is exceedingly stupid.

Write your app so it can run on bare metal, install with apt, yum or your tool(s) of choice for your org. Build it so it scales diagonally, and works against spot instances where you can (because sometimes more or less cores are cheaper). Dont even get me started on the nonsense of everyone and their ideas for "secrets management", it makes me miss LDAP.

The author mentions Jsonnet in the appendix[^1]:

> I never properly evaluated Jsonnet, but probably I should. Superficially it looks like one of the more mature formats, and in many ways it looks similar to RCL. Its has a page comparing itself against other configuration languages.

[^1]: https://ruudvanasseldonk.com/2024/a-reasonable-configuration...

What do you do when your normal programming language stops being your normal programming language (you add a language, switch languages), but you want to preserve details of the configuration? Translate it all into your new language(s)? How do you keep these things synced up? You extract the details into a configuration language/serialization format and then deserialize in every language you work with.

Embedding your configuration in your application language only works well as long as you have one application language. (Or perhaps you use Lua or TCL which are both almost trivially embedded into every other language.)

Hum, most systems do not go down that hole at all. Most software stop at most at hierarchical parameters.

For the ones that do go down the hole, you are almost always better on separating them into components, to minimize the ones that need complex configuration, and accelerating the journey of those small pieces. (But yeah, it would be nice to settle on a good workflow description language that isn't a makefile.)

Now, it seems that everybody that is pushing those high-complexity languages wants an infrastructure description language, and just keeps calling it by "configuration language". Since those two problems are completely different, insisting on using the wrong name is quite harmful to the goal.

I quite like what has been come up with here. In particular, I understand exactly how HCL would drive someone down this path, as it is infuriating to try to get that language to compute what you want computed.

I think at the end of the day, k8s YAML is focused on the datatype, i.e., what would be the result of your `rcl evaluate`. I do think this would be a much saner path than what Helm provides, though, and Helm's textual templating, as opposed to understanding values and building the actual datastructures, and then converting that to a format like JSON or YAML … is the wrong path. (I.e., I can see RCL being a possible replacement for Helm.)

> The language is a superset of json.

I'm going to introduce what I think is pretty much a universal law: languages claiming to be supersets of other languages are not supersets.

In the case of JSON, there's basically one counter-example that breaks all alleged supersets:

  "\ud83d\udca9"

And if we try it:

  » printf '"\\ud83d\\udca9"' | cargo r -- evaluate
      Finished dev [unoptimized + debuginfo] target(s) in 0.01s
       Running `target/debug/rcl evaluate`
  stdin:1:2
    ╷
  1 │ "\ud83d\udca9"
    ╵  ^~~~~~
  Error: Invalid escape sequence: not a Unicode scalar value.

  Help: For code points beyond U+FFFF, use '\u{...}' instead of a surrogate pair.

Now! This to me is not a bug in RCL: this particular facet of JSON is utter crazy town, and I would strongly encourage you to not adopt it. (Since down this road lies madness, like unpaired surrogates. JSON's grammar & standard is sloppy here, and JSON/JS's syntax of using the UTF-16 encoding, and not just the scalar value … it's the part of JavaScript that is just what JS is, but is the part that we shouldn't be copying.)

It is much saner to just have a flag/way to indicate "my input is JSON" and then to just parse it via an actual JSON parser. Then let RCL evolve on its own merits. If there's a lot of happy overlap, and most JSON documents are blissfully polyglots with RCL, that's fine too / a happy little accident. (But the option is important if you want to apply it somewhere programmatically, where the inputs are JSON.)

YAML breaks the same way, too: it too is a "superset" of JSON that isn't.