Remember when everything was configured using XML? Seemed good, but the contents meaning were mysterious and once you encountered that first error it was downhill from there. They solved that with scheme support right? No. That added more work to implement and barely addressed syntax issues doing almost nothing for larger issue of semantics.
Thank goodness YAML came along! I’m being sarcastic. The name alone, Yet Another Markup Language, should have set expectations, and proving we just don’t learn, YAML configurations went through the same evolution as XML. When the things starting getting out of control people added “API Versions” which made the tooling more complex, marginally helped on syntax and didn’t really address semantics. Sigh. In YAML’s defence is more compact and easier to read… which means you get to the frustration stage faster.
My current work has me working with YAML configurations for Kubernetes, Helm, Istio, Helmfile, Kustomize, Github Actions and probably some I’ve forgotten. In not a single instance have I thought: Thank you YAML for being the best tool for the job!
Consider Maven Vs Gradle
Maven used XML for it’s configuration, Gradle went with a domain specific language (DSL). Maven configuration files are huge, confusing, and get pretty hackey when they are complex. Sometimes they you even resort to embedding Ant’s XML in a pinch. Gradle started with Groovy and moved to Kotlin. Trying to code up a Maven configuration in a markup language was like trying to fit a square peg in a round hole. Where as the Gradle DSL is expressive, powerful and most IDEs can really assist your writing them. I moved to Gradle as soon as it was stable, and to the Kotlin DSL as soon as that was stable. I never looked back with any regrets. Employing a DSL for configuration will likely bloat the the tool chain size a bit, and slow it down a tad, but those costs are worth the improvements in increased power and ease of development.