1. 11
  1. 7

    It doesn’t sound like they’ve fixed the complaints articulated here.

    That’s enough to make me prefer other options when they’re available to me.

    1. 12

      No one likes breaking changes either. Damned if you do, damned if you don’t.

      1. 4

        Damned if you do, damned if you don’t.

        I agree. And to strain the reference: So dammit, I will use something else.

        1. 6

          All JSON is valid YAML. Just use JSON.

          1. 4

            They don’t really target similar uses though? I don’t love YAML, but JSON is not really meant for human authoring, especially when large or repetitive

            1. 5

              TOML is really the best of both worlds IMO. Easy to read/write, hard to screw up.

              I’d also say that there’s really no human serialization language that handles repetition well. YAML has its anchors and stuff but that’s footgun city. HCL has for_each which is good but also has a steep learning curve. Writing real code and dumping to something else is my preferred method if HCL isn’t an option.

              1. 3

                I don’t mind YAML anchors so much, but if I really want this kind of feature I’m reaching for Dhall for sure

              2. 2

                All JSON is also valid UCL as well. UCL actually supports all of the things I want from a human-friendly configuration language, such as well-defined semantics for loading multiple files with overrides (including deletion), so if you want to avoid complex parsing in your main application then you can have a stand-alone unprivileged process that parses UCL and generates JSON.

                Anything where I might want YAML, I’ve found either JSON or UCL a better choice. JSON is much simpler to parse and has good (small!) high-performance parsers, UCL is more human-friendly. YAML is somewhere between the two.

              3. 3

                One small nit: the YAML spec disallows tabs, while JSON allows them. In practice, I don’t know of any YAML parser implementations that will actually complain, though.

                1. 2

                  I haven’t used a YAML parser that allows tabs in YAML syntax, but appearing inside inline/json syntax they may be more lax

                2. 1

                  This is the only good thing about YAML

            2. 4

              I agree with several of the issues pointed out on that page and it’s sibling pages, but some of the headache experienced is a direct result of libyaml(and thus pyyaml). It still doesn’t properly support YAML 1.2, which defines booleans as true/false. That is still a nasty thing though when wanting to use the literal word true or false, but at least it avoids the n,no,y,yes, and the various case differences. 1.2 only supports true, false.

              libyaml also doesn’t generate errors on duplicate keys, which is incredibly frustrating as well.

              The criticism of implicit typing, tagging, typing, flows, yaml -> language datatype, etc. are all spot on. They are prone to errors and in the latter case make it really easy to introduce security issues.

              1. 2

                That is still a nasty thing though when wanting to use the literal word true or false, but at least it avoids the n,no,y,yes, and the various case differences. 1.2 only supports true, false.

                Are you sure? https://yaml.org/spec/1.2.2/#other-schemas seems to be saying that it’s fine to extend the rules for interpreting untagged nodes in arbitrary ways. That wouldn’t be part of the “core schema”, but then nothing in the spec says parsers have to implement the core schema.

                1. 2

                  Whoops. You are correct. The three described schemas are just recommendations. The lack of a required schema is frustrating.

                  The described recommended schemas define booleans as true, false, which is a change from what versions less than 1.2 had.

                  I’ll say that I personally get frustrated quickly with yaml.

              2. 3

                Any language that supports bare strings will have issues when you also have asciinumeric keywords.

                An issue? Sure, but more a tradeoff than anything else.

                1. 4

                  The problem with the bare string interpretation, as I see it, is not so much the fact that it exists. It’s that it’s not part of the spec proper, but a set of recommended additional tags. What do you think 2001:40:0:0:0:0:0:1 is? Not the number 5603385600000001? The YAML spec, to the extent it has an opinion, actually agrees, but many YAML parsers will interpret it as 5603385600000001 by default, because they implement the optional timestamp type.

                  YAML 1.2 doesn’t recommend https://yaml.org/type/ any more, but it doesn’t disallow it, either. The best part of all this is that there are no strict rules about which types parsers should implement. If you use a bare string anywhere in a YAML document, even one that already has a well-understood meaning, the spec doesn’t guarantee that it will keep its meaning tomorrow.