Hacker News new | ask | show | jobs
by cromka 781 days ago
Isn’t it why toml is seemingly increasingly used to replace yaml in projects?
3 comments

In my experience toml is worse at anything complex. It's nice as an .ini replacement but makes even yaml look sane in comparison if you want to use it for very complex or deeply nested stuff. But it wasn't designed to do that anyways
Am I alone in greatly preferring nesting in toml compared with yaml?
Did you try to convert any mid-complexity ansible role into toml? It was very interesting exercise for me and vastly conclusive.
I hope not, toml is even worse at complex things and just slightly better at the stuff that isn't confusing. Add a k:v to a mildly complex dict.

At this point, I'm pushing into a place where I'm just going to switch to go because its getting to be a mess.

It’s insanely better at config.

It’s about as bad at being a programming language or data structure serialization format, though.

But yaml is fine at config, it sucks at looping, conditionals and data structures, if you aren't fixing that its just another standard we have to learn, so thanks for that
No, it's not fine at config. It's a bag of weird corner cases and incompatible revisions which you have to debug instead of doing your actual work.

Here's a good summary: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...

Nope it isn't.

There are so many things that aren't expressible in TOML that any anywhat complex system will want... it's not even a contender.

So, one problem a lot of configurations are trying to solve: modularity. I.e. how to allow different actors to change the parts of the configuration they want. Everything under /etc nowadays is of a form /etc/*.d/*.* that is all configurations are directories of multiple files with some ridiculous rules (like "prefix file names with digits so that they sort and apply in the "right" order etc.) XML had a better approach with namespaces and schema, but maybe not perfect.

Polymorphism. Any non-trivial configuration system will have plenty of repeating parts. NetworkManager connection configurations? -- They are all derived from the same "template". Systemd device services -- same thing, they are all coming from the same "template". There are plenty more examples of this. But, languages like YAML or TOML don't have a concept of polymorphism in them. This is never encoded in the configuration itself. Instead, every tool that needs to be configured and needs some degree of polymorphism rolls its own version.

Constraints. It's often impossible to describe the desired configuration through specifying the exact values. Often the goal can be described as "less than" or "given the value of X, Y should be multiple of X" and so on. Such concepts, are, again, not expressible in TOML or YAML and friends.

NB. Types are a kind of constraints.

Identity. It's often necessary in configuration to distinguish between two sub-sections that look the same and two sub-sections that designate the same exact object. Like, when configuring VMs with eg. disks: are they supposed to mount the same disk, or does each VM need a separate disk, that just has the same physical characteristics?

But then, what is a config file if not a representation of a data structure?
With the restriction that it has to be represented in human-friendly text.

JSON’s a crazy-bad serialization format, too, for that matter. It doesn’t even know what a damn integer is.

Toml is great for simple use-cases. For complex ones you have the same problem that yaml has: Templating a language with significant whitespace via text substitution is a horrible horrible idea. Somehow this sad state of affairs has become industry standard.
Its not even the white space, a food liter or language server can handle that. It's not that, as much ad the fact that the most complex data structure is a list.

If you want to get crazy, you can push a dict into a list and operated on it but it gets tough at the second level. And don't get me started on if/else statements.