I actually tried to demonstrate this with numbers a while back. I tried taking a few random JSON files as a control and representing them with StrictYAML and TOML and the TOML varied from 30% to 100% longer.
There is an element of opinion here, but there is no question that equivalent TOML files are longer, and most of that is syntax.
It's much more pronounced when you have more than one or two levels of nesting. With 4 or 5 levels of object nesting TOML files grow huge, whereas YAML is still fine.
>Further, adding an errant '-' and accidentally creating another object is real common in YAML
Yep, this is one of the things that type safety helps with though. Similarly it's quite easy to mess up an indent in YAML, but a schema can catch that stuff.
> It's much more pronounced when you have more than one or two levels of nesting.
Yes. That's a clear indication that either you configuration type structure is badly designed, or that you aren't trying to create a configuration type and should use some data encoding or programing language that fits your problem better.
I guarantee you the people using your software will curse you every time they try to edit a YAML file with more than 3 levels of nesting.
I confess I feel strongly in opposite directions on this. I'm pretty biased against YAML: I think it's way way too complex, and its "declarative" nature and broad feature set essentially make it a complexity magnet. I've seen hellish YAML files, and it's also pretty common to combine them with Jinja (or w/e) for extra hellsauce.
But it's declarative, which is really cool! What else would you realistically use for like, AWS infra? The JSON version is so much worse. Using Python or whatever is its own can of worms.
This is the kind of thing that stuff like CUE and Dhall are aiming at, and I welcome it. It feels like they're the way out here.
Oh I don't doubt that there are various inefficiencies, but I dispute the characterization that this inefficiency is "wrong". I think it's clear by now that there's not "1 text format to rule them all", whether we're talking XML, JSON, HTML, SGML, TOML, YAML, JSON, RFC 2822, CSV, or whatever. Depending on your use case, one of these is better than the others. Like I definitely don't want to serialize objects into TOML. I also definitely don't want to deal with JSON for configuration.
> ...but a schema can catch that stuff.
100%; it's amazing to me the number of projects that essentially accept arbitrary structures and/or values here. I think no matter whether you're using YAML/TOML/JSON/etc. you oughta be using something to validate.
There is an element of opinion here, but there is no question that equivalent TOML files are longer, and most of that is syntax.
It's much more pronounced when you have more than one or two levels of nesting. With 4 or 5 levels of object nesting TOML files grow huge, whereas YAML is still fine.
>Further, adding an errant '-' and accidentally creating another object is real common in YAML
Yep, this is one of the things that type safety helps with though. Similarly it's quite easy to mess up an indent in YAML, but a schema can catch that stuff.