Curious at to what technologies you work with? The work that I do and tools that I use have all manner of configuration file syntaxes and languages and a big headache for doing sysadmin work is trying to remember if a particular .rc file uses INI, YAML, JSON, TOML or some home rolled nonsense.

At work, we needed a config file for some employees to sit alongside a custom (non-web) script I wrote. These employees have zero technical knowledge (like, they wouldn't know basic HTML), and I found TOML to be pretty easy for them to understand. It looks like this:

    # config.toml

    [[podcasts]]
    title="Podcast 1"
    export_label="Label 1"

    [[podcasts]]
    title="Podcast 2"
    export_label="Label 2"

It's flat for them, but gives me a nice `$podcasts` array of nested objects to work with and they don't need to worry about curly braces, indenting, etc. They can just copy/paste three lines if they need to "add" a new one.

Of course, my use case is pretty simple and these are simple string values, but I found it pretty nice.

I moved some config files from json to yaml. Maintaining the documentation became a lot easier, because before I had a document describing every config option, which I had to maintain separately, instead now I have comments in the config file itself.

Note that now you have "the Norway problem" instead. https://hitchdev.com/strictyaml/why/implicit-typing-removed/

There's a whole spectrum of config formats including JSON, JSON5, strict YAML, YAML. It's quite messy.

The norway problem is not a problem if you use yaml 1.2.

Which is 14 years old.

EDIT: this sounded adversarial which was not my intention. Plenty of libraries do not support 1.2 which sucks, I just meant that it's something solved in theory a long time ago.

Could you explain further? The link contradicts this:

> The most tragic aspect of this bug, however, is that it is intended behavior according to the YAML 1.2 specification. The real fix requires explicitly disregarding the spec - which is why most YAML parsers have it.

the article is wrong, from what I can tell.

From https://yaml.org/spec/1.2.2/ext/changes/

> Changes in version 1.2 (revision 1.2.0) (2009-07-21)

> [...]

> Only true and false strings are parsed as booleans (including True and TRUE); y, yes, on, and their negative counterparts are parsed as strings. Underlines _ cannot be used within numerical values.

The link is wrong. YAML 1.2 fixed this.

I found yaml to be surprisingly complex and tricky to write for how simple it looks.

It is made to be beautiful and easy for a human to read, but the trade-off are a lot of implicit rules you need to be aware of.

The point of strictyaml is to fix that. The trade off is that you need to define a schema up front.

It also reminds me the syntax of INI files.

I just started a new job where we’re writing a lot of Python, and I’m seeing TOML everywhere