Maybe that's just my personal bias, but I feel like the relative simplicity of JSON is a strong feature in its favor. As a developer, I have very clear understanding of the data I'm reading, and with that I can more easily make safer and more stable code.
Not saying refs/id are bad, but at least with a uniform syntax and language support, you don't have to reimplement custom cross-reference resolvers.
Most people don't use these features.
https://github.com/search?o=desc&p=2&q=data+language%3AYAML&...
> YAML is what people turn to who need these kind of advanced feautures
might be literally true, it is also true that
YAML is what many people turn to even if they don't use those features
So the original concern of
> Powerful but pretty catastrophic if you use (naive) recursion to analyze a user-submitted data structure.
is probably reasonable.
There is a pretty good likelihood that many YAML users (i.e. the app developers) are unaware of the power exposed in the format, and the possible consequences of parsing & walking user input.
It brings back all sorts of memories of XML entity attacks, etc. When developers build simple data interchange methods on top of complex formats that they don't fully understand, all sorts of issues emerge.
It's not YAML's problem per se - it's very helpful that there is a commonly used, complex data format for people who need such features. It would be far worse if everyone was inventing their own solution for this - but the reality on the ground is still pretty messy.
They are - HJSON, JSON5, TOML, etc. Most of these reference YAML's overcomplicated spec as a reason for their existence.
It does seem to be a rarely used feature though. Furthermore it confuses non-programmers who otherwise are happy with YAML (I've tested this, it really does).
Given all of this, and given that what it does can be easily achieved in other ways that don't require the feature, I think it's a net negative overall to have it in the spec.
I'm certain this feature is a major reason why YAML was chosen for CI config over TOML or JSON, and the way it's used in those config files is, as I said, _not_ recursive, so the issue discussed here isn't relevant. Rejecting recursive definitions can be a sensible improvement.
What other ways do you have in mind that would be a viable replacement?
Where there is not very much repetition required, simply use repetition instead (e.g. in the above example I would just copy & paste use-db to the relevant locations). The increased readability makes it worth the repetition where there's not a lot of it.
Where there is a lot of repetition I'd consider that a bug or feature required in the schema and would refactor the YAML schema and the parsing code so that less repetition is necessary for most configs.
I don't consider the above CI config particularly easy to understand and even with the node anchors and references there's a bunch of repetition (e.g spinach 1, spinach 2, spinach 3, etc.). That's partly because of the node anchors and references. It would look better if they refactored the schema.
Without a looping or sequence construct, this will be hard to avoid, and once you go that route, you might as well adopt a Lisp as your config syntax.
Before there was XML, there was SGML, and SGML has DSSSL, which was a Scheme dialect, and that was a brilliant idea which has been ditched for XML and its surrounding specs. S-Expressions are natural for the task. There are still prominent uses of S-Expressions, even in the OCaml world, where Jane Street uses it for configuration and serialization.
The full power of a Lisp may be too much and risky, but you can restrict the spec and allow only certain constructs, so that you can ensure it will evaluate to a result in a quick and deterministic way.
The little "templating" feature used in gitlab-ci.yml is a huge benefit, and as long as parsers limit the feature, it's a good compromise between complexity and comfort.
There is a lot of experience with using Lisp for configuration, and that experience can be leveraged to come up with a good S-Expressions based config format that's flexible, deterministic, and known to terminate in constant time. If you're careful with the spec, you could even validate the config fully.