It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments!
If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when I was doing this evaluation for my own project.
Personally, after doing a few pyproject.toml files, I still find it confusing and awkward as soon as you get past simple headers and key-values.
TOML is like YAML, it translates to "jsonic" types, but JSON's virtue is that simple 1:1 mapping between syntax and data.
TOML and YAML both have non-obvious syntax and there's a layer of translation you have to do to understand what you're actually generating.
But I don't really want to generate a big blob of objects, arrays and such, I want to configure something. I think that's why none of these languages work very well.
specifically TOML supports a syntax that allows to write documents like: (not actual syntax)
a.b=1
a.c=2
d=3
a.e =4
So the criticism is that (in various cases) you need to read the entire document to be sure to have fully parsed one subtree of the document.
Which you can pretend is a strength, since I consider doing that an anti-pattern. But it is a valid critique.
However, the TOML they offer as a comparison to the StrictYAML is probably auto-generated (they do say "serialized TOML equivalent") and it's quite a bit noisier than it has to be.
TOML deliberately has a couple of ways of writing arrays, and a one-line short format for maps: you're supposed to alternate these, and this technique could eliminate most of the repetition in that particular file.
I still wouldn't choose TOML for a complex tree of user stories where the keys are all long strings of English: that's an example of the kind of thing where you might talk yourself out of using it!
Here's the counterpoint I want to offer: stories of YAML "configuration languages" escaping confinement and becoming headache-inducing repositories of monstrous complexity are practically cliche at this point.
Part of why that is, is that you don't pay for that complexity "up front": It's just a nice list! It's easy to read!
I would add one thing to TOML if I could: it should default to a string for the value part of a key-value pair, if it can't make anything else. So
my_val = 42
my_string = "42"
my_regex = ^\"(\\.|[^\"])*\"
Could you provide an example of what you mean, or point to some such? We're having a spot of trouble with arrays of maps ourselves.
This breaks down when things get really branchy. TOML really expects keys to be symbols rather than strings.
struct Foo {
int bar;
Baz baz;
int quux;
}
[foo]
bar = 5
[foo.baz]
...
quux = 6
The serializer has to be smart enough to recognize that primitive fields have to be serialized before object fields. As a practical example, Rust's TOML library is not smart enough to do so, though it does at least detect when this would happen and fails with a runtime error. (The workaround is to change your type definition to reorder the fields yourself.)
Ref: https://play.rust-lang.org/?version=stable&mode=debug&editio...
What it means in practice is that if you want to use [table] syntax because it's more readable for this one key, you have to move it to the very end, away from the keys it was related to.
Wasn't impressed.
[0] i mean this:
[[abc]]
param="foo"
[[abc]]
param="bar"
[[abc]]
param="baz"
However, a benefit to TOML's weakness with complex data is it encourages developers to keep things simple.
Dhall is going to be better than writing an inner-language monster of a config language, in YAML, TOML, or JSON. Let someone else do the work, I agree.
But if the goal is to have a human-editable file that loads a few values into a map, and it often is, TOML is pretty nice.
I think we've all been burned by 'configuration languages' which take on the complexity of a full programming language, in a worst-of-both-worlds sort of way. But sometimes you just want to change a font, or specify tabs-or-spaces, or set a non-default remote.