Yeah! Starlark (mentioned in the article as well) is also not Turing complete. It’s a dialect of Python which makes it a bit easier to adopt if you’re familiar with Python. I’m using the Rust implementation for a small personal project that needs configuring.
In general, I’m happy that YAML exists, it’s perfectly fine for 80% of (my) use-cases. But when projects become too big, and a lot of YAML is required, then managing things with it becomes an issue increasingly.
I reckon this will become more pressing in the medium-term future, with Kubernetes and similar technologies becoming the norm, and along them quite complex infrastructure setups. So I really hope one of those projects trying to solve the configuration issue will be successful. CUE looks like the most likely contender at the moment, IMHO.
I choose YAML over JSON for a project recently where the client is supposed to edit the metadata, but I think this was probably a poor choice due to the fiddlyness of getting whitespace consistent.
YAML is only a superset of JSON after a certain YAML revision. Most YAML libraries I’ve dealt with don’t actually implement that version of YAML, and so will reject JSON data due to syntax errors.
Your mileage may vary, check your library documentation.
I hate YAML. But then I remember that if I use JSON it should pass. So I use JSON for YAML configuration. Easily scriptable, templateable, etc. Do whatever, JSON is still one of the simplest, hardest-to-fuck-up ways of configuring.
Except that it doesn´t allow comments, so you can´t write what/why about a specific configuration, and it breaks with a trailing comma at the end of a list or dict.
They’re talking about supplying a YAML parser with JSON; the YAML parser will accept the JSON along with the comments, because YAML is a superset of JSON.
Except that it doesn´t allow comments, so you can´t write what/why about a specific configuration,
Ignoring that a trivial workaround is to use another key as comment, ej. foo-comment documents the foo entry, if you need to document your configuration options consider reducing the configuration options of your application. It is true for code and truer for configuration options. Most of production outages are due to stuff being misconfigured and each configuration option multiplies the possible code paths.
and it breaks with a trailing comma at the end of a list or dict.
Which is something that you can trivially solve in an after save hook with a few lines of elisp (and I assume VimL as well) and forget about it. Nowadays with prettier I’m sure it is trivial in VSCode and most editors as well.
On the YAML side, excessive nesting is a frequent UX problem to dig yourself into. Say if you use rails and YAML for locatization. ,The way to ‘fix’ it is to use folding, which in turn requires the language to do properly. Something that is not easy due to its ‘beautiful’ syntax.
When people say ‘avoid complexity’ YAML is one of the first things that comes to mind. Completely unnecessary complexity w/o any relation to business rules.
I’d prefer to just your language to configure things (like Django does it), it has richer data types ej. first class dates. You can’t really do that if you want to use the same configuration file across different languages but that is rarely the case.
Often the big problem with logic programming isn’t getting it to run, but getting it to run fast. A lot of confusing stuff in production logic code are optimizations.
If we’re working in a restricted domain, we can presumably minimize performance traps, so it should be easier to understand.
For you maybe. I straight up struggle to understand logic programmes and have never succeeded at writing anything more than exercises for university courses.
I think it’s a paradigm that excludes more people than templating does.
There’s no logic programming involved in cue. Cue is just a configuration language that uses a novel approach for “reducing boilerplate” and making it possible to validate that a configuration conforms to a set of defined constraints. Or to put it in even plainer language, it has some kind of types and does some kind of templating. The “kind of” is new, so yes, you’ll have to make some effort to understand it at first. As with anything.
The article sure makes it sound like logic programming:
CUE is based on a different model of logic programming that makes it well suited for configuration. The language’s foundations make tasks like validation, templating, querying, and code generation first class features. CUE is designed around graph unification where sets of types and values can be modeled as directed graphs and then unified
A different model of logic programming, it’s the first sentence in your quote. Did you actually read any of the examples? They read like typed YAML with struct merging. It’s like logic programming because of how the values and types in structs merge together: you can’t contradict yourself and you can’t be ambiguous. CUE schemas look much more like SQL column types and CHECK constraints than classic logic programming.
// contradiction, 1 is not a string
{ key: string } & { key: 1 }
// contradiction, 1 is not 2
{ key: 1 } & { key: 2 }
// no contradiction, 2 is an int
{ key: int | 1 } & { key: 2 }
// ambiguous, is key 1 or 2?
{ key: 1 | 2 }
// not ambiguous, 1 is more specific than int
{ key: int | 1 }
As in the original post’s examples, this kind of merging gets used primarily for templating.
I love dhall as a non turing complete config language.
Sort of related: I had no idea what Dhall was for but recently listened to the CoRecursive podcast with the creator and found it interesting https://podcasts.google.com/?feed=aHR0cHM6Ly9jb3JlY3Vyc2l2ZS5jb20vZmVlZA&episode=Y2I0NmZhNmZjOTQ5NGY1OTkxZWE2ZDZkNzU2MDM0Mjk&hl=en&ved=2ahUKEwjlo8OLnu_lAhUGrVkKHXOiAOkQieUEegQIABAG&ep=6&at=1573924629200
The CoRecursive site isn’t working for some reason so I shared the google podcasts link instead.
This episode of CoRecursive mentions this SERadio podcast episode about Dhall too: https://www.se-radio.net/2019/08/episode-375-gabriel-gonzalez-on-configuration/
Yeah! Starlark (mentioned in the article as well) is also not Turing complete. It’s a dialect of Python which makes it a bit easier to adopt if you’re familiar with Python. I’m using the Rust implementation for a small personal project that needs configuring.
In general, I’m happy that YAML exists, it’s perfectly fine for 80% of (my) use-cases. But when projects become too big, and a lot of YAML is required, then managing things with it becomes an issue increasingly.
I reckon this will become more pressing in the medium-term future, with Kubernetes and similar technologies becoming the norm, and along them quite complex infrastructure setups. So I really hope one of those projects trying to solve the configuration issue will be successful. CUE looks like the most likely contender at the moment, IMHO.
It’s kinda funny that the proposed solution to the complex tooling problem is another tool :)
I choose YAML over JSON for a project recently where the client is supposed to edit the metadata, but I think this was probably a poor choice due to the fiddlyness of getting whitespace consistent.
YAML is a superset of JSON, so if you don’t use any of the more advanced features of YAML you can still use JSON for the templating, etc.
YAML is only a superset of JSON after a certain YAML revision. Most YAML libraries I’ve dealt with don’t actually implement that version of YAML, and so will reject JSON data due to syntax errors.
Your mileage may vary, check your library documentation.
If I have the client write JSON then it’s not obvious to me what benefit I get from using YAML at all.
I hate YAML. But then I remember that if I use JSON it should pass. So I use JSON for YAML configuration. Easily scriptable, templateable, etc. Do whatever, JSON is still one of the simplest, hardest-to-fuck-up ways of configuring.
Except that it doesn´t allow comments, so you can´t write what/why about a specific configuration, and it breaks with a trailing comma at the end of a list or dict.
They’re talking about supplying a YAML parser with JSON; the YAML parser will accept the JSON along with the comments, because YAML is a superset of JSON.
Ignoring that a trivial workaround is to use another key as comment, ej. foo-comment documents the foo entry, if you need to document your configuration options consider reducing the configuration options of your application. It is true for code and truer for configuration options. Most of production outages are due to stuff being misconfigured and each configuration option multiplies the possible code paths.
Which is something that you can trivially solve in an after save hook with a few lines of elisp (and I assume VimL as well) and forget about it. Nowadays with prettier I’m sure it is trivial in VSCode and most editors as well.
On the YAML side, excessive nesting is a frequent UX problem to dig yourself into. Say if you use rails and YAML for locatization. ,The way to ‘fix’ it is to use folding, which in turn requires the language to do properly. Something that is not easy due to its ‘beautiful’ syntax.
When people say ‘avoid complexity’ YAML is one of the first things that comes to mind. Completely unnecessary complexity w/o any relation to business rules.
I’d prefer to just your language to configure things (like Django does it), it has richer data types ej. first class dates. You can’t really do that if you want to use the same configuration file across different languages but that is rarely the case.
I like this idea, especially that you could easily define, share or import validation and defaults.
Language itself is quite easy to read, too.
Ah yes instead of templating things and using macro expansion we’re going to make our lives easier by using logic programming instead.
Unfortunately, I’m not smart enough to understand any logic programs I’ve ever seen, so I’ll have to stick with macro expansion.
Often the big problem with logic programming isn’t getting it to run, but getting it to run fast. A lot of confusing stuff in production logic code are optimizations.
If we’re working in a restricted domain, we can presumably minimize performance traps, so it should be easier to understand.
As someone vaguely aware of logic programming but who’s never managed to find a use case for it, do you have any suggestions for further reading?
Mostly speaking from secondhand discussions with logic folk and my experience with constraint solving, so I don’t have anything to recommend, sorry :/
https://github.com/larsyencken/marelle is using prolog for system configuration
For you maybe. I straight up struggle to understand logic programmes and have never succeeded at writing anything more than exercises for university courses.
I think it’s a paradigm that excludes more people than templating does.
There’s no logic programming involved in cue. Cue is just a configuration language that uses a novel approach for “reducing boilerplate” and making it possible to validate that a configuration conforms to a set of defined constraints. Or to put it in even plainer language, it has some kind of types and does some kind of templating. The “kind of” is new, so yes, you’ll have to make some effort to understand it at first. As with anything.
The article sure makes it sound like logic programming:
A different model of logic programming, it’s the first sentence in your quote. Did you actually read any of the examples? They read like typed YAML with struct merging. It’s like logic programming because of how the values and types in structs merge together: you can’t contradict yourself and you can’t be ambiguous. CUE schemas look much more like SQL column types and CHECK constraints than classic logic programming.
As in the original post’s examples, this kind of merging gets used primarily for templating.