4 ms·

I share your, and all Norwegians', distaste for YAML. One saving grace I have found is that YAML is a superset of JSON. JSON isn't great, but it's certainly bet

I share your, and all Norwegians', distaste for YAML. One saving grace I have found is that YAML is a superset of JSON. JSON isn't great, but it's certainly better than YAML. I toyed around with dhall to generate k8s deployments. It was fantastic, but then I realized there was no chance that others would be willing to learn FP. Cue is pretty great, but it still has many sharp edges in the tooling. Ultimately, though, all configuration files tend toward turing completeness. Just use an actual programming language. If you need to dynamically parameterize it then you can import a JSON file or whatever.

TechBro8615 4y ago
Upon further reflection, it's not actually YAML I have a problem with, so much as the (lack of) composability of YAML. As soon as you're dealing with multiple files and want to "include" something in one way or another, it seems like every DevOps software has its own semi-standard way of allowing that. As annoying as the parsing quirks of YAML are, they don't bite me that often. What bites me is the proliferation of YAML files in an effort to DRY my config files with whatever primitive imitation of a templating language I can use as the common denominator of the various tools consuming them. I just checked our monorepo, and we have ~93 YAML files related in some way to DevOps.
- zamalek 4y ago
  My main issue is that YAML is used as a [bad] programming language. To make matters worse, in the domains where it's typically used (DevOps) the "developer inner loop" is usually minutes long (e.g. GitHub actions). Having to actually do the dangerous things that you typically do with YAML in order to test the YAML is insane!
brodouevencode 4y ago
> JSON isn't great, but it's certainly better than YAML. This is the first time I've ever seen someone say this. Why do you think it's better?
- TechBro8615 4y ago
  As a human, I'd rather write YAML than JSON. But if I'm writing code, I'd rather write code that parses JSON. The problem is that the two often conflict with each other, because I'm writing code to parse config written by a human. My rule of thumb is that any autogenerated communication between services can be done over JSON (assuming some more efficient serialization format isn't available), but if a human needs to maintain it (and check it into a repo with diffs) then it should be YAML.
  - brodouevencode 4y ago
    I agree with this point. I would also say that while HCL gets a lot of hate from the developers it really is an easy language to learn and use. Yes it's another language but the language itself I found to be very natural for declaring desired state. Last year I spent two half-days training my team on it (I have a lot of experience with it) and they picked it up rather well. Previous teams I worked with had similar results. It may not be their favorite language, but it's not as bad as cloudformation or a heavy, cumbersome CDK.
- ElectricalUnion 4y ago
  Not OP but https://noyaml.com/ https://noyaml.com/ summarizes most of it. TL;DR: It has way too many opinionated things builtin, too many ways to do the same thing. As a additional note, unlike JSON that has the awesome tooling available (`jq` is reasonably widespread, you can count on python/perl/node being almost everywhere), it has nothing that (because of the multiple opinionated ways) will reliably read your files or not mangle your desired output in some way or another -- except if you limit your YAML to just a embedded JSON.
  - TechBro8615 4y ago
    There actually is a yq [0] which I've used effectively for basic parsing and manipulation tasks on the command line. But I've no idea how well it handles YAML corner cases or how many advanced features it's missing compared to jq. [0] https://github.com/mikefarah/yq https://github.com/mikefarah/yq

TechBro8615 4y ago

Upon further reflection, it's not actually YAML I have a problem with, so much as the (lack of) composability of YAML. As soon as you're dealing with multiple files and want to "include" something in one way or another, it seems like every DevOps software has its own semi-standard way of allowing that. As annoying as the parsing quirks of YAML are, they don't bite me that often. What bites me is the proliferation of YAML files in an effort to DRY my config files with whatever primitive imitation of a templating language I can use as the common denominator of the various tools consuming them. I just checked our monorepo, and we have ~93 YAML files related in some way to DevOps.

zamalek 4y ago
My main issue is that YAML is used as a [bad] programming language. To make matters worse, in the domains where it's typically used (DevOps) the "developer inner loop" is usually minutes long (e.g. GitHub actions). Having to actually do the dangerous things that you typically do with YAML in order to test the YAML is insane!

brodouevencode 4y ago

> JSON isn't great, but it's certainly better than YAML. This is the first time I've ever seen someone say this. Why do you think it's better?

TechBro8615 4y ago
As a human, I'd rather write YAML than JSON. But if I'm writing code, I'd rather write code that parses JSON. The problem is that the two often conflict with each other, because I'm writing code to parse config written by a human. My rule of thumb is that any autogenerated communication between services can be done over JSON (assuming some more efficient serialization format isn't available), but if a human needs to maintain it (and check it into a repo with diffs) then it should be YAML.
- brodouevencode 4y ago
  I agree with this point. I would also say that while HCL gets a lot of hate from the developers it really is an easy language to learn and use. Yes it's another language but the language itself I found to be very natural for declaring desired state. Last year I spent two half-days training my team on it (I have a lot of experience with it) and they picked it up rather well. Previous teams I worked with had similar results. It may not be their favorite language, but it's not as bad as cloudformation or a heavy, cumbersome CDK.
ElectricalUnion 4y ago
Not OP but https://noyaml.com/ https://noyaml.com/ summarizes most of it. TL;DR: It has way too many opinionated things builtin, too many ways to do the same thing. As a additional note, unlike JSON that has the awesome tooling available (`jq` is reasonably widespread, you can count on python/perl/node being almost everywhere), it has nothing that (because of the multiple opinionated ways) will reliably read your files or not mangle your desired output in some way or another -- except if you limit your YAML to just a embedded JSON.
- TechBro8615 4y ago
  There actually is a yq [0] which I've used effectively for basic parsing and manipulation tasks on the command line. But I've no idea how well it handles YAML corner cases or how many advanced features it's missing compared to jq. [0] https://github.com/mikefarah/yq https://github.com/mikefarah/yq