1. 13

Learning YAML might be table stakes, but we still need to strive for a better solution. One that’s more human friendly.


  2. 7

    I’ve found that a big “saving grace” for YAML is that anything that is valid JSON is also valid YAML. My go-to fix for having to work with large amounts of YAML has been to generate JSON via jsonnet and use that instead.

    1. 6

      After getting into some really annoying OpenAPI YAML files, and then fighting with it in docker ecosystem and elsewhere, I’m pretty over it.

      For all the pissing and moaning, I am perfectly content to use JSON for everything. The only features it is actually missing in my opinion are:

      • Heredoc support
      • Multi-line string support
      • RFC3339 date support
      • Better Unicode support
      • Proper support for 754 floating point special values ( +/- inf, nan, etc.)

      That’s it. That’s all I want. Everybody wants to add other shit–knock it off.

      1. 3

        Heredoc support Multi-line string support RFC3339 date support Better Unicode support Proper support for 754 floating point special values ( +/- inf, nan, etc.)

        This. I’ve been using TOML for some things lately and other than array of tables and table of tables it just sort of works.

        1. 1

          I believe the problem with YAML is that it tries to be both a human-facing configuration language a machine-friendly interchange language. I really like UCL for separating the two concerns. UCL provides a set of rich features for things like includes with priority-based merging and unit suffixes but can also take a config directory and merge the result into a single JSON document (or some other serialisation). Your front end can take complex UCL structures but then send the back end a single blob that’s easier to parse.

          1. 1

            JSON is also missing binary-data support, and needs it badly.

            1. 1

              You can base-64 encode binary data and store it as a string, so it doesn’t make my list.

              1. 1

                Ah, but there is no way in JSON to indicate that a string contains Base64-encoded binary data, rather than is a string which happens to decode to Base64 without errors. As an example, is the string “your” Base64-encoded binary data, or an English word?

                1. 1

                  There’s also no way to tell if a field 1.0 is dealing with pounds or kilograms, right?

                  That’s a type problem, which JSON mostly doesn’t (and in my opinion, shouldn’t) provide.

                  1. 1

                    I don’t think it’s a typing issue, so much as it’s a value issue: what is the value of the string "foot"? Is it the bytes 146, 157, 157, 164 or is it the bytes 126, 138, 45?

                    Although, if types don’t matter, one might argue against distinguishing "2.0" and 2.0. Heck, we could just adopt Tcl literals, where everything is a string. Instead of {"foo":2, "bar": "baz"} we could just have foo 2 bar baz. That wouldn’t bother me too much, to be honest, but I think most folks wouldn’t care for it!

          2. 3

            The absolute worst offender is helm templated yaml, it’s very easy to screw up the level of nesting. At best you get an invalid yaml file and it fails to apply. At worst you get a valid yaml file that’s doesn’t do what you want it to do and you don’t realize until later.

            1. 3

              Just use XML. Especially because versioning is really easy and just works.

              E. g. You have a new config version 2, so your define your new schema, and the XSLT to convert your config version 1 to config version 2, and never have to think about it again (or deal with multiple config versions in your application).

              1. 1

                JSON is terribly unreadable with large configurations and YAML has it’s quirks. People rag on XML because its the cool thing to do, but it gets the job done.

              2. 2

                Unpopular opinion: I abolutely love YAML as a human readable data format. It has all the right features. Unfortunately it is abused with layers of templating, and is used for “programming in YAML”.

                Nice features:

                • “here document”/multiline string support. Sometimes very handly. I don’t know of other serialization format that knows it.
                • id support, to be able to represent cycles in object graphs natively
                • no need for explicit closing of structures, good streamability. (I have seen xml/json logging, either with extreme overhead, or with malformed, contents)
                • pretty human readable, better than JSON.
                • comments
                • the indentation based syntax is not that bad (though I’m also OK with it in Python and F#)

                YAML is nice for configs, and many simple serialization tasks (though not efficient at that). Just don’t use it as a programming language.

                Also: RFC format is not that nice imho.