Comment by chillfox
3 years ago
Yep,
Although I do feel like there is a case to be made that if you need a Turing complete configuration language then in most cases you failed your users by pushing too many decisions on to them instead of deciding on sensible defaults.
And if you are dealing with one of the rare cases where Turing complete configuration is desirable then maybe use Lua or something like that instead.
I'm not defending YAML. YAML is terrible. It's even worse with logic and/or templates (looking at you, Ansible). Toml is certainly better but I'm still baffled as to why we don't have a "better YAML". YAML could almost be okay.
There's also Lua, which is a full Turing complete language but is still pretty nice for writing config files, and is easy to embed.
Followup to my own post: don't forget about Scheme! Same nice properties as Lua, but you get some extra conveniences from using s-expressions (which can represent objects somewhat more flexibly, like XML, than Lua, which is more or less 1:1 with JSON).
There's StrictYAML[1][2]. Can't say I've used it as let's face it, most projects bind themselves to a config language - whether that be YAML, JSON, HCL or whatever - but I'd like to.
[1] https://hitchdev.com/strictyaml/
[2] https://github.com/crdoconnor/strictyaml
Yeah, I think it's because nobody sat down and methodically created it.
People create config languages that work for their use case and then it is just a happy accident if it works for other things.
I don't think anyone has put serous effort into designing a configuration language. And by that I mean collect use cases, study how other config languages does things, make drafts, and test them. etc...
Terraforms HCL is well designed.
I know a lot of people hate it but I find it to be the only configuration language that makes any sense for moderately large configs.
It’s short, readable, unambiguous, great IDE support. Got built in logic, variables, templates, functions and references to other resources - without being Turing complete imperative language, and without becoming a xml monstrosity.
Seriously there is nothing even close to it. Tell me one reasonable alternative in wide use that’s not just some preprocessor bolted onto yaml, like Helm charts or Ansible jinja templates.
2 replies →
Yeah absolutely. I think there are four corners to the square: "meant to be written by humans/meant to be written by computers" and "meant to be read by humans/not meant to be read by humans". JSON is the king of meant to be written by computers read by humans, grpc and swift and protobuf and arrow can duke it out the written by computer/not read corner. We are missing good options in written by humans half.
Dhall and Cue come to mind as ones that _feel_ more designed
https://github.com/dhall-lang/dhall-lang
https://cuelang.org/docs/usecases/configuration/
6 replies →
> Yeah, I think it's because nobody sat down and methodically created it.
I think it's the opposite. There isn't a single config file that suits all needs.
Especially when you realize config isn't a single thing.
http://mikehadlow.blogspot.com/2012/05/configuration-complex...
1 reply →
About Ansible, I think it gained it's success partially due to YAML.
Ansible is worse than Puppet and CFEngine in many ways, but it is superior in the user interface.
It managed to not only be a config management solution, but provide a universal config language that most apps could be configured with. So for a lot of use cases, if you know Anisible/YAML then you don't have to learn a new configuration language on top of learning a new application.
The problem with Ansible is it's not universal, because most app playbooks, are configured in the worst possible way. In my experience typically you get handed an Ansible script, something which you'd hoped was declarative but isn't (like a version that apt-get grabs isn't fixed, or even, gets patched) then suddenly a downstream templated command fucks up, and the person who wrote the script isn't around anymore (or you don't trust their chops because they are a blowhard that worked at Google/Facebook and had a coddling ops team behind them in the past) or worse it's from "community" and has a billion hidden settings that you can't be bothered to grok - and so you have to dig so many layers down that you are better off just fucking rewriting the Ansible script to do the one thing which probably should have been four lines.
In any case, I found Ansible scripts to have like a 3 month half life. If we were lucky. I'm not bitter.
1 reply →
Early on, Ansible was primarily agent-less from the start which made it ridiculously easy to sneak into existing infrastructure and manual workflows. I probably would not have been able to stand up Puppet or Salt or whatever but I could run Ansible all by myself with no one to stop me :).
I'm curious what your thoughts are on a config language I'm working on.
GitHub.com/vitiral/zoa
It has both binary and textual representation (with the first byte being able to distinguish them), and the syntax is clean enough I'm planning on extending it into a markup language as well.
Even if you have sensible defaults don't you still need to be able to parse configured changes?
Not always, sometimes all other options are just wrong. Or you can auto detect the correct setting.