As a data format, yaml is extremely complicated and it has many footguns. In this post I explain some of those pitfalls by means of an example, and I suggest a few simpler and safer yaml alternatives.
A 10 minute read covering some YAML edge-cases that you should have in mind when writing complex YAML files
I have literally never seen yaml used as a data storage format, only as a configuration language. Ansible, Kubernetes, Home manager, netplan, and many, many other examples of yaml as a configuration language, but I cannot think of an example of yaml as a data storage format off the top of my head.
Given the:
package {
name my-pkg
version "1.2.3"
dependencies {
// Nodes can have standalone values as well as// key/value pairs.
lodash "^3.2.1" optional=#true alias=underscore
}
On the README of the KDL Github, it looks like KDL has a similar goal to be a configuration langauge, rather than a data storage format.
Yaml is a data storage format, why should it have any kind of programmability or even turning completeness?
Those things should be done in the program that uses the data not inside of the data itself.
I have literally never seen yaml used as a data storage format, only as a configuration language. Ansible, Kubernetes, Home manager, netplan, and many, many other examples of yaml as a configuration language, but I cannot think of an example of yaml as a data storage format off the top of my head.
Given the:
package { name my-pkg version "1.2.3" dependencies { // Nodes can have standalone values as well as // key/value pairs. lodash "^3.2.1" optional=#true alias=underscore }On the README of the KDL Github, it looks like KDL has a similar goal to be a configuration langauge, rather than a data storage format.
Configuration is a type of stored data.
Configuration is data that is read and parsed on program startup.
But limiting it to configuration storage only makes it only more absurd to implement turning completeness into the language.