I think I get what the article is saying. I don't think they expressed it very well. Here's a concrete example of what I think they're complaining about. From a Kubernetes Deployment manifest: - name: DATABASE_URL valueFrom: secretKeyRef: name: db-conn key: uri That valueFrom.secretKeyRef.{name, key} structure is an "exploded AST" — something that in any programming language, you'd be chastised for writing out as a s…
YAML and Configuration Files
41–50 of 96 posts
Re: YAML and Configuration Files
#42Earlier quoted context omitted.
yaml (and json) gives configuration files much-needed hierarchy and structure, which is unbounded (within reason), not limited syntactically or inherently like simpler configuration formats including toml. yaml adds to that comments and a pleasant readable layout, even if it requires a little bit more from the editor to make it pretty. With that, I don't think yaml has much competition.
Toml has unlimited nesting as well. There are also many formats that are "better json" that have comments, multiline strings, trailing commas etc. Such as hjson, json5 (and variants such as json6, jsonX, etc.) and hocon. As well as more sophisticated languages like jsonnet, dhal, and cue. Many of these can be "compiled" to JSON. There is plenty of competition, but for some reason, YAML seems to be the most popular.
Re: YAML and Configuration Files
#43Re: YAML and Configuration Files
#44I think Cue[1] is a much more powerful and useful config format that also has the ability to generate validated JSON or YAML if needed. [1]: https://cuelang.org
Re: YAML and Configuration Files
#45After resisting it for many years I've finally settled on YAML as my default configuration format. I need a way of expressing the core data types of JSON (key/value mappings aka "objects", arrays, strings, integers, floating points and booleans) - plus comments, and multi-line strings that insulate me from complex escaping rules. YAML does that. It's not perfect, but it's good enough. And in Python I can use yaml.saf…
YAML seems to be one of the most polarizing things in the software industry. I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language. I use it in pretty much every project, but I've worked with people who've said they hate it with a burning passion. And it's kind of a trope to see anti-YAML manifestos on HN and /r/programm…
If only the people behind Ansible agreed with this. Jinja+YAML templating is just utterly terrible.
Re: YAML and Configuration Files
#46Earlier quoted context omitted.
YAML seems to be one of the most polarizing things in the software industry. I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language. I use it in pretty much every project, but I've worked with people who've said they hate it with a burning passion. And it's kind of a trope to see anti-YAML manifestos on HN and /r/programm…
> I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language If only the people behind Ansible agreed with this. Jinja+YAML templating is just utterly terrible.
Re: YAML and Configuration Files
#47I think I get what the article is saying. I don't think they expressed it very well. Here's a concrete example of what I think they're complaining about. From a Kubernetes Deployment manifest: - name: DATABASE_URL valueFrom: secretKeyRef: name: db-conn key: uri That valueFrom.secretKeyRef.{name, key} structure is an "exploded AST" — something that in any programming language, you'd be chastised for writing out as a s…
There are at least a couple of prominent versions of that: a great dynamic language version is JavaScript template literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...>; or in the static language world there's C++ user-defined literals https://en.cppreference.com/w/cpp/language/user_literal> (tho if I remember correctly they are horrible for strings unless you are using a recent version of C++)
Re: YAML and Configuration Files
#48> YAML isn't a configuration language or a configuration language format, it's a serialization format I think YAML is even worse as a serialization format than a configuration format. It has too many ambiguities, implementations are too inconsistent, and many implementations are insecure by default with untrusted input. > Using a good custom designed configuration file format instead of trying to shove things through…
> I think YAML is even worse as a serialization format than a configuration format. This. I find YAML to be the least offensive option for configuration and one of the worst for serialization. I might be misinformed, but I find it absurd that in 2021 we still don't have a default, universally available tool that supports the basic table stakes without headache: 1. core data types (number, string, etc) 2. lists, maps,…
0. Looks essentially the same as JSON
1. Core data types, and customizable data types can be added easily.
2. Arrays, Objects, and arbitrary nesting.
3. Comments ( both /* */ and // format )
4. Multiline strings ( by default; carriage returns are no problem within strings )
5. It is JSON with relaxed restrictions and slight addition for actual named types.
6. I've written C, Perl, and Golang implementations so far.
Re: YAML and Configuration Files
#49Earlier quoted context omitted.
YAML seems to be one of the most polarizing things in the software industry. I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language. I use it in pretty much every project, but I've worked with people who've said they hate it with a burning passion. And it's kind of a trope to see anti-YAML manifestos on HN and /r/programm…
> it becomes a pain once you start trying to use it like a DSL or templating language. I like YAML and use it a lot. But I'd argue the fact that it even allows/encourages you to do such things with it is a design flaw that ultimately has kept it from Do One Thing Well.
No coercion of y/n/yes/no/on/off to booleans (these were also removed in the official YAML 1.2 spec, thankfully), no direct object representations, no anchors or references, etc.
Re: YAML and Configuration Files
#50Earlier quoted context omitted.
> I think YAML is even worse as a serialization format than a configuration format. This. I find YAML to be the least offensive option for configuration and one of the worst for serialization. I might be misinformed, but I find it absurd that in 2021 we still don't have a default, universally available tool that supports the basic table stakes without headache: 1. core data types (number, string, etc) 2. lists, maps,…
It's a real shame JSON doesn't have 3 and 4, because it would be so easy and it's otherwise pretty much perfect imo. No ambiguity, every value type can be identified by its first character, clean and reasonably minimal syntax.
might not be as "common" but it has good implementations for many languages.