As someone who's spent most of their career in cloud IAC, and likes to think they are pretty read up on the latest going on in that world, if you didn't know better you'd think YAML is one of the greatest threats facing mankind. There are plenty of things I certainly hate about it, but every configuration syntax I've ever used I have similar gripes about. It's like once a month this kind of "The world is growing tired of yaml" claim is just thrown out there like everyone just agrees with it. Choose something that works for you. This author repeatedly mentions TOML but there are plenty of issues with that one I could point out too. Syntax is one very small part of what makes an ecosystem great or not so great. Most of my exposure to yaml is helm chart templates, which admittedly is not pure YAML, but it works fine enough for me, at least to where I don't feel like writing lengthy blog posts about how much I hate it. I even wrote a library that converts yaml templates to HCL for internal use because I got so sick of people having this exact same argument like it deeply mattered. And guess what? They hate the HCL too.
I also think that a lot of the problems with yaml specifically are overblown, but this post is actually not about that!
It is specifically saying the same problem exists in JSON/YAML/TOML, etc, which is that all these configuration languages don't have any real means of abstraction, and ultimately aren't expressive enough do to the job we require of them.
as soon as you are templating config files with other configs, I agree, I have sorely felt this limitation with helm charts
Serious question: do people who work with these config files frequently, or on large such files, use simple text editors, or are there "smart" editors that do things like prevent you from making typos or inserting the wrong data type, similar to an HTML form that does basic validation or a DB schema that rejects bad data?
There is no single cure-all, of course, but surely we should be relying on computers to do much of the heavy lifting when it comes to validation and verification of these files, not just as linters after the fact but in realtime while we're editing, and with some sort of knowledge (even if derived programmatically) of what is right and what is wrong so we no longer have to worry about simple footguns.
I think one of the problems of those "configuration languages" is that you can extract semantic information without knowing the target, e.g., with has a specific meaning in GitHub Actions but it is otherwise an unremarkable word in the YAML specification.
But when working with real programming languages it is completely different, you can take semantic information from the current code, and you can have things like types to give you safety.
The problem is most configuration languages are declarative vs imperative like most “real” languages are. You could probably levy the same complaint against declarative languages in general - it’s just a different way of thinking
Nix as used in NixOS is a declarative language and there is none of the issues I cited by being a "real" programming language (or as the article talks about, having "abstractions" like builtin.map). You can pretty easily setup a LSP to get code-completion (even between different projects, like NixOS vs Home-Manager). There is no proper type system in Nix but the module system does supplement it well.
HCL is generally great, but has some issues with clarity of transformation to the underlying data structures.
But anytime someone suggests TOML I have to double check to be sure they are serious because the TOML syntax for anything more complicated than single-layer maps is mind-bogglingly confusing to me. This is not a serious alternative to YAML.
It's like bike shedding. It's a side effect of mixed expertise (and confidence) working together on things that are only partially understood by all. When something is clearly outside one's expertise, they are content to leave it to others. But then you'll get minor questions with low stakes like "what color to paint the shed". And how everyone feels like they can participate, so suddenly there's a huge discussion / debate / argument about a very, very minor thing.
Don't want to sound too harsh, but to me HCL is even worse than plain YAML.
By expressiveness, HCL is somewhat similar to Ansible-flavoured YAML - in both you need to use magic keywords to create any kind of abstraction (e.g. a loop).
HCL is worse than regular YAML because there's only one "true" parser for it, that is official Hashicorp's HCL parser. So if you are locked into Golang ecosystem, then sure it can work for you, otherwise you are out of luck.
There are a couple of tools that convert HCL into JSON, I tried both, they somewhat work, but in the end of the day it's a big hack. At that point I just gave up on using HCL and started using something else that generates JSON.
Hope you find some configuration layer that fits your users more than HCL or YAML.
