5 ms·

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 baffl

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.

vitiral 5y ago
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.
chillfox 5y ago
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...
- svieira 5y ago
  Dhall and Cue come to mind as ones that _feel_ more designed https://github.com/dhall-lang/dhall-lang https://github.com/dhall-lang/dhall-lang https://cuelang.org/docs/usecases/configuration/ https://cuelang.org/docs/usecases/configuration/
  - chillfox 5y ago
    Interesting... Me, the programmer finds those kinda cool. And the sysadmin in me developed a dislike of both within 1 minute of looking at them. Honestly, I think a good configuration library should be more than a spec, it should come with a library that handles parsing/validation. See, there are two sides to configuration, the user and the program. Knowledge about the values, defaults and types should live on the program side and should be documented. Then the user side of configuration can be clean and easy to read/write and most important of all, allow the user to accomplish the most common configuration without having to learn a new config language on top of learning the application.
    - BiteCode_dev 5y ago
      > Honestly, I think a good configuration library should be more than a spec, it should come with a library that handles parsing/validation You just described CUELang. The type system allows to define a schema as well as the data, in the same file, or in 2 separate ones. Then you can call either a cli tool (that works on linux, windows or mac) or use the Go lib (or bind to it). For compat, cue can import and export to yaml, json and protobuf, as well as validate them.
      - chillfox 5y ago
        Ok, you have convinced me to give it a serious look.
      - stavros 5y ago
        Isn't Dhall basically the same (=have the same set of features)?
        BiteCode_dev 5y ago
        In the same way python and js are basically the same.
        stavros 5y ago
        Exactly. So if I'm going to learn/use one of them, there's no clear winner, really. Both also seem to also have about the same amount of adoption (zero?).
- dnautics 5y ago
  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.
- Too 5y ago
  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.
  - mirekrusin 5y ago
    Cuelang?
  - randomswede 5y ago
    There's a world of difference between "simple configuration needs" and "complex configuration needs". I will take a kubernetes deployment manifest as an example that you would want to express in a hypothetically perfect configuration language. Now, eventueally, you end up in the "containers" bit of the pod template inside the deployment spec. And in that, you can (and arguably should) set resources. But, in an ideal world, when you set a CPU request (or, possibly, limit, but I will go with request for now) for an image that has a Go binary in it, you probably also want to have a "GOMAXPROCS" environment variable added that is the ceiling of your CPU allocation. And if you add a memory limit, and the image has a Java binary in it, you probably want to add a few of the Java memory-tuning flags. And it is actually REALLY important that you don't repeat yourself here. In the small, it's fine, but if you end up in a position where you need to provide more, or less, RAM or CPU, on short notice (because after all, configuration files drive what you have in production, and mutating configuration is how you solve problems at speed, when you have an outage), any "you have to carefully put the identical thing in multiple places" is exactly how you end up with shit not fixing themselves. So, yeah, as much hate as it gets, BCL may genuinely be better than every other configuration language I have had the misfortune to work with. And one of the things I looked forward to, when I left the G, was to never ever in my life have to see or think about BCL ever again. And then I saw what the world at large are content with. It is bloody depressing is what it is.
- Ygg2 5y ago
  > 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-complexity-clock.html?m=1 http://mikehadlow.blogspot.com/2012/05/configuration-complex...
  - chillfox 5y ago
    I guess that could also be the case. I haven’t studied it, I am just generally feeling unhappy about most software configuration.
nerdponx 5y ago
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.
- nerdponx 5y ago
  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).
chillfox 5y ago
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.
- dnautics 5y ago
  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.
  - chillfox 5y ago
    haha, I can go on lengthy rants about every single configuration management system that I have used. My dream configuration system should revert to default when the config is removed (keeping data). Have a simple/easy user interface. Have maintained modules with sane defaults for the 500 most common server software. I would rather there be no module than an abandoned one with unsafe defaults, that way it is clear that I would have to maintain my own if I want to use that particular piece of software. Performant, it really shouldn't take more than a few minutes to apply a config change. No more than 30 min for initial run.
- Steltek 5y ago
  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 :).
brigandish 5y ago
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/ https://hitchdev.com/strictyaml/ [2] https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml

vitiral 5y ago

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.

chillfox 5y ago

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...

svieira 5y ago
Dhall and Cue come to mind as ones that _feel_ more designed https://github.com/dhall-lang/dhall-lang https://github.com/dhall-lang/dhall-lang https://cuelang.org/docs/usecases/configuration/ https://cuelang.org/docs/usecases/configuration/
- chillfox 5y ago
  Interesting... Me, the programmer finds those kinda cool. And the sysadmin in me developed a dislike of both within 1 minute of looking at them. Honestly, I think a good configuration library should be more than a spec, it should come with a library that handles parsing/validation. See, there are two sides to configuration, the user and the program. Knowledge about the values, defaults and types should live on the program side and should be documented. Then the user side of configuration can be clean and easy to read/write and most important of all, allow the user to accomplish the most common configuration without having to learn a new config language on top of learning the application.
  - BiteCode_dev 5y ago
    > Honestly, I think a good configuration library should be more than a spec, it should come with a library that handles parsing/validation You just described CUELang. The type system allows to define a schema as well as the data, in the same file, or in 2 separate ones. Then you can call either a cli tool (that works on linux, windows or mac) or use the Go lib (or bind to it). For compat, cue can import and export to yaml, json and protobuf, as well as validate them.
    - chillfox 5y ago
      Ok, you have convinced me to give it a serious look.
    - stavros 5y ago
      Isn't Dhall basically the same (=have the same set of features)?
      - BiteCode_dev 5y ago
        In the same way python and js are basically the same.
        stavros 5y ago
        Exactly. So if I'm going to learn/use one of them, there's no clear winner, really. Both also seem to also have about the same amount of adoption (zero?).
dnautics 5y ago
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.
Too 5y ago
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.
- mirekrusin 5y ago
  Cuelang?
- randomswede 5y ago
  There's a world of difference between "simple configuration needs" and "complex configuration needs". I will take a kubernetes deployment manifest as an example that you would want to express in a hypothetically perfect configuration language. Now, eventueally, you end up in the "containers" bit of the pod template inside the deployment spec. And in that, you can (and arguably should) set resources. But, in an ideal world, when you set a CPU request (or, possibly, limit, but I will go with request for now) for an image that has a Go binary in it, you probably also want to have a "GOMAXPROCS" environment variable added that is the ceiling of your CPU allocation. And if you add a memory limit, and the image has a Java binary in it, you probably want to add a few of the Java memory-tuning flags. And it is actually REALLY important that you don't repeat yourself here. In the small, it's fine, but if you end up in a position where you need to provide more, or less, RAM or CPU, on short notice (because after all, configuration files drive what you have in production, and mutating configuration is how you solve problems at speed, when you have an outage), any "you have to carefully put the identical thing in multiple places" is exactly how you end up with shit not fixing themselves. So, yeah, as much hate as it gets, BCL may genuinely be better than every other configuration language I have had the misfortune to work with. And one of the things I looked forward to, when I left the G, was to never ever in my life have to see or think about BCL ever again. And then I saw what the world at large are content with. It is bloody depressing is what it is.
Ygg2 5y ago
> 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-complexity-clock.html?m=1 http://mikehadlow.blogspot.com/2012/05/configuration-complex...
- chillfox 5y ago
  I guess that could also be the case. I haven’t studied it, I am just generally feeling unhappy about most software configuration.

nerdponx 5y ago

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.

nerdponx 5y ago
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).

chillfox 5y ago

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.

dnautics 5y ago
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.
- chillfox 5y ago
  haha, I can go on lengthy rants about every single configuration management system that I have used. My dream configuration system should revert to default when the config is removed (keeping data). Have a simple/easy user interface. Have maintained modules with sane defaults for the 500 most common server software. I would rather there be no module than an abandoned one with unsafe defaults, that way it is clear that I would have to maintain my own if I want to use that particular piece of software. Performant, it really shouldn't take more than a few minutes to apply a config change. No more than 30 min for initial run.
Steltek 5y ago
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 :).

brigandish 5y ago

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/ https://hitchdev.com/strictyaml/ [2] https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml