Live data from Hacker News

TOML – Tom's Obvious, Minimal Language

toml.io

1–10 of 163 posts

Re: TOML – Tom's Obvious, Minimal Language

#3
Of configuration file formats, TOML is my favorite. It hits the right balance of power and simplicity, it's been able to handle my needs with minimal effort and fuss.

I tried Python's INI for configuration, but it was both too simple and too complex at the same time, very frustrating.

YAML is a nightmare, the formatting is way too easy to get wrong and accidentally break your configuration.

JSON is too strict/simple. You can't even have trailing commas in a list!

Re: TOML – Tom's Obvious, Minimal Language

#4
TOML superficially looks clean, but it has many of the same problems other similar languages have.

Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte arrays.

Most disappointingly, TOML has a "table" type, but unfortunately, just like other "RPC as Config" formats, the column names need to be repeated for every row, which is just crazy. It also makes no sense to talk about "arrays of tables", which are actually just "rows" in standard terminology. An array of rows... is a table.

Here is a terse example of the type of thing that does come up very often in bulk provisioning of the type that needs config files full of data:

    @"
    Server,Subnet,IP
    db01,databases,10.1.2.3
    db02,databases,10.1.2.4
    user01,filers,10.3.10.1
    user02,filers,10.3.10.2
    "@ | ConvertFrom-Csv | New-VMBuildScript.ps1
I'm yet to see a config file format that can even approach this in terms of its readability and terseness.

Re: TOML – Tom's Obvious, Minimal Language

#5

TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…

It all depends on context. Honestly, I've rarely (never?) needed to store GUIDs, IP addresses, or byte arrays in a configuration file. So that's not as common of a situation as you're thinking - maybe for your experience, but there are many different uses for configuration.

The example you give would suck in any configuration file format, and honestly I don't believe it belongs in a configuration file - I'd put it into a data file (e.g. a CSV as you show) and then in the configuration file I'd include a pointer to that data file to be loaded separately.

Re: TOML – Tom's Obvious, Minimal Language

#6

TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…

I would love to see YAML or EDN-style tagging in TOML for use cases like marking strings as IP addresses.

Re: TOML – Tom's Obvious, Minimal Language

#7

TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…

I think that's two different senses of the word "configuration". TOML is great for key/value data where you want a little bit of structure / nesting / categorization on the keys, but probably not more than one level or so. Think of, say, the preferences for your text editor, or (as widely used) a metadata file for a library that specifies its dependencies and build configuration.

It looks like you have tabular data where you don't need any nesting, every row has the exact same structure, and there's no single column of a row that you'd call "the value." TOML is not well-suited for this, and I don't think it sets out to be. I see how you'd call it "configuration," but it seems like a pretty different category of thing.

(I'd buy the argument that "table" is a poor choice of name for that TOML construct; I'd personally have called it a "multi-value" or something. It's an array of objects, and there's no guarantee that the objects have homogeneous structure, and it's usually useful for them to have different structures.)

Re: TOML – Tom's Obvious, Minimal Language

#10
I'm personally sick of yet-another-config-formats. Why did designing metaformats become cool?

They all have warts because using the same symbolic notation for data and structure leads to encoding issues that have cognitive overhead.

So instead of getting used to the pratfalls involved in making mistakes in one format/library set, we can do it in a whole bunch of different ones. And of course if anyone uses the new format much much, we'll get multiple, slightly incompatible versions, all with different bugs.

Thanks?

Post reply on HN