3 ms·

> 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

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