[pavon]

INI-like formats are perfectly fine for config files with at most one layer of nesting/sections. TOML is a perfectly fine INI-like parser. Its definitions and support for strings, numbers, comments, sections and simple arrays are great. But its main claim to fame is extending INI to support arbitrary levels nesting of arrays and dictionaries like JSON, and IMO it does a horrible job at it.

With JSON, YAML, XML and many other formats, the syntax for nesting has a visual appearance that matches the logical nesting. TOML does not. You have to maintain a mental model of the data structure, and slot the flat syntax into that structure.

Furthermore, there are multiple ways to express the same thing like

  [fruit.apple]
  color = "red"

or

  [fruit]
  apple.color = "red"

It isn't always obvious which approach is more appropriate for a task, and mixing them creates a big mess.

And the more nested the format becomes, with arrays of dicts, or dicts of arrays, the harder it is to follow.

[kibwen]

> And the more nested the format becomes, with arrays of dicts, or dicts of arrays, the harder it is to follow.

While I have some minor annoyances with TOML, I counterintuitively consider it a strength of the format that nesting quickly becomes untenable, because it produces pressure on the designers of config file schemas to keep nesting to a minimum.

Maybe some projects have a legitimate need for something more complex, but IMO config files are at their best when they're just key-value pairs organized into sections.

[integralid]

As far as I can see, nobody originally constrained the problem to config files. So I guess the problem with TOML is that it's only good for config files, while JSON and TOML are general purpose.

[kibwen]

Yes, I think that's a fair characterization. The priorities of config file formats are different than the priorities of human-readable arbitrary data serialization and transmission formats.