It's possible that's part of what's going on, but... I don't think so. Or, not so cleanly. YAML options aren't choices, they're things you can do if you end up wanting to.
This is a theme in Ruby (and then Rails) programming. There's a bunch of stuff you can use, but you don't have to, and probably won't. There's an effect there, but it's not the same as choice paralysis.
--
I don't see what you see - that YAML was designed with the idea that options are intrinsicially valuable - it said, "Here's a thing to do. What's the simplest way to do this?".
Well-executed simplicity leads to options - think grep. There's a bunch of options when using grep, but really, it just does the one thing... but then there's a bunch of ways to use that one thing.
Again, this is a Ruby thing. There's more than one way to do it because there's more than one situation in which you'll need to. Have a simple array? Brackets. Have a not simple array? Dash.
In either case, it's pretty much the simplest way to do it, but one doesn't work (as well, or at all) for the other situation.
Further, "YAML is not as popular as JSON" is an observational fact, not something we can argue away. It's worth trying to figure out why and learning what we can from it. I've made my proposal. There are other options ("Javascript is a steamroller"). But I'm not really a big fan of the evergreen "other people are just too stupid to see the obvious truth" explanation, which is generally the one that seems to be given to explain why YAML hasn't beaten JSON. That explanation is almost always wrong. (Only almost, though.)
You're saying that the popularity of JSON is directly related to the popularity of implementing JSON, which is due to the simplicity of it's implementation, as compared to YAML. This seems somewhat reasonable, but I don't think it can cover everything.
Can you point me at an example of what you're talking about? I can't really evaluate what you're saying with the information I have.
This isn't to say that I would prefer JSON over XML - I most definitely wouldn't - but it is just as abused lately. I hope we will see its demise soon and something coming out of the YAML line (e.g. TOML) getting more widespread.
I only skimmed the Github readme, what makes TOML better than YAML?
That's at the expense of a few things, however. For instance, array can't contain objects of different types; even [ 1, 2.0 ] is not allowed. Also, having a map (aka. a dictionary) in an array is really awkward to write, and there probably are cases that simply can't be expressed.
It has first-class dates, though.
I wrote about the state of settings formats around the time that TOML was born: <http://espadrine.tumblr.com/post/44576550326/a-history-of-se....
And thanks for Dotset - didn't know it exists, but it looks very, very neat.
In most but the most basic configurations, however, I found myself missing some of variables, inheritance, dates. TOML solves the last two, but as you point out it has limitations. YAML solves the first two, though in a bit of an ugly and obscure way. No wonder Salt and Ansible, two heavy users of YAML configs both pass it through templating engines to reach their goals.
For the lack of better alternatives, I usually end up with a Django-style Python module holding the configuration when I want it to be powerful. It still freaks (non-Python) people out though.
Lua is not a half-bad choice if you ask me. It takes some time getting used to, but it's fast to interpret, and at least one project that I know of - Lsyncd - is making an absolutely great layered configuration on top of it.
On top of that schema assisted JSON serialization can be almost as fast as something like protobuf, but you don't have to deal with binary or a lot of codegen on both sides.
PS - I'm not counting the inherent different from simply more characters as important:
<obj> <string>foo</string> <obj>
obj: string: foo
{ "obj": { "string":"foo"} }
That's not important. If you have enough extra characters for that to be important, you have enough data that you should probably do something other than serialize to text.
YAML is missing things such as quote marks so you have to do things such as type inference to determine what an item is, which decreases speed.
I don't know the specifics more than that, but just do serialization benchmarks and you'll see it pretty quickly.
Sometimes I feel like I'll go to Ruby hell for saying this, but as far as I can tell, XML is actually really good at that part... because it's a markup syntax, not a data syntax, while JSON and YAML are data syntaxes, not markups.
Seriously. Everything the others can do, it does better (or, at least as good - not gonna argue that YAML tags are pretty); and most importantly, optionally. (Plus, it's got a few features the others don't)
You don't have to use block text. You don't have to use quotations. You don't have to use tags, or references. A simple usage of YAML is simpler than any other. A complex use of YAML is still less complex than many uses of XML, but has the same information content.