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
YAML is truly an untenable format. I’m personally excited for KDL to stabilize and hopefully see wider adoption, but in the meantime I’m fine sticking with JSON most of the time.
That has XML semantics, which isn’t what people want in the vast majority of cases. They want JSON semantics because it matches programming language object models.
I don’t see anything about turing completeness or programmatic capabilities in their github. Any language that doesn’t have the programmatic abilities will inevitably get them hacked on when someone needs them, like what happened to yaml a bunch of times for a bunch of different software. This is one of people’s many frustrations with yaml, the fact that doing a loop, an if statement, or templating, is different for every single software that uses yaml. Even within Kubernetes, there exists different ways to do templates.
I would much rather see the language consider those things first, then see it repeat one of the biggest mistakes of yaml. This is why I am more eager for things like nickel, or even Nix as a configuration language, and am skeptical of any new standard that doesn’t have those features.
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 truly an untenable format. I’m personally excited for KDL to stabilize and hopefully see wider adoption, but in the meantime I’m fine sticking with JSON most of the time.
That has XML semantics, which isn’t what people want in the vast majority of cases. They want JSON semantics because it matches programming language object models.
XML semantics are good for documents.
I don’t see anything about turing completeness or programmatic capabilities in their github. Any language that doesn’t have the programmatic abilities will inevitably get them hacked on when someone needs them, like what happened to yaml a bunch of times for a bunch of different software. This is one of people’s many frustrations with yaml, the fact that doing a loop, an if statement, or templating, is different for every single software that uses yaml. Even within Kubernetes, there exists different ways to do templates.
I would much rather see the language consider those things first, then see it repeat one of the biggest mistakes of yaml. This is why I am more eager for things like nickel, or even Nix as a configuration language, and am skeptical of any new standard that doesn’t have those features.
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.