Live data from Hacker News

TOML – Tom's Obvious, Minimal Language

toml.io

121–130 of 163 posts

Re: TOML – Tom's Obvious, Minimal Language

#121
post #106

I discovered TOML a couple of years ago when I started playing with Hugo, as it was Hugo's format of choice for configuration files. I honestly find TOML harder to read and more complicated to use than YAML. I tried to look into it but frankly I still haven't found a use case where it made more sense to use TOML.

Interesting how differently competent people can perceive things. To me, YAML is a cruel joke, and I carry suspicions about the competence of anyone who opts to use it out of all possible options. I think I've even grown to like XML configuration over it.

+1

Re: TOML – Tom's Obvious, Minimal Language

#122

Earlier quoted context omitted.

You're assuming that all languages have a "System.Guid" type that the configuration value can be parsed into. If you want a strongly type configuration that works across many languages, you'll need to also provide the per-language implementation of those types to fill the gaps. You'll notice that JSON, YAML, INI, and XML also do not have IP address nor GUID types. What configuration format does meet your approval?

> What configuration format does meet your approval? None at the moment. My problem with all of them is that I can't scan them visually to spot typos or mistakes. They break the content up and move related data too far apart for the inconsistencies to be immediately apparent. Don't laugh, but in the absence of better options, I prefer to use Excel. With tabular data, things that belong together are visually adjacent.…

It sounds like you should store your configuration in some sort of KVS (Consul or etcd) or database (SQL) with a frontend rather than flat text files. There exists tooling for all of that. If you're really going for Excel, why not even make a plugin that hooks in to it. Personally I'd find that horrible, but if it works for you and your team has no objections, why not.

I'd wager that the major reason no one has taken it that far is that your preferences are very rare.

But who knows, if you build it and make it available maybe others will find it useful too.

You're probably getting downvoted because unless I'm misinterpreting your previous comments, you're mixing up abstraction levels and concerns when you're talking about types.

Personally I think yaml is a terrible and confusing format in general (yes I do understand it quite well), I see your point with JSON, but I wouldn't personally say it's a fundamental issue the way you're describing it.

Re: TOML – Tom's Obvious, Minimal Language

#123

Earlier quoted context omitted.

I've been using TOML recently and what displeases me most is that almost all string values need to be quoted.

Array of objects is terrible in TOML. I grudgingly use it only because it's categorically better than YAML IMO and INI isn't powerful enough.

At least in YAML you only have to quote a string if it contains a colon-space and can therefore be inferred to be a dict. In TOML all strings are quoted: https://github.com/toml-lang/toml/issues/105#issuecomment-14...

Re: TOML – Tom's Obvious, Minimal Language

#124

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…

That's not config data that you have here, that's your program input (hint: you pipe it to stdin).

TOML is for config, config that users edit by hand, not input.

Re: TOML – Tom's Obvious, Minimal Language

#125
post #106

I discovered TOML a couple of years ago when I started playing with Hugo, as it was Hugo's format of choice for configuration files. I honestly find TOML harder to read and more complicated to use than YAML. I tried to look into it but frankly I still haven't found a use case where it made more sense to use TOML.

[deleted]

Re: TOML – Tom's Obvious, Minimal Language

#126
post #115

Earlier quoted context omitted.

I've been using TOML recently and what displeases me most is that almost all string values need to be quoted.

Otoh, I got plenty of support requests from people not understanding that the space at the end of a line in an .ini file is part of the value. (app is using glib ini parser) Quoting at least makes it clear what's part of the value.

What sort of nightmare format from hell has significant whitespace at end of line?

Re: TOML – Tom's Obvious, Minimal Language

#127

Earlier quoted context omitted.

JSON5 pretty much addresses all the problems with JSON as a config format. I'd love for it to just replace JSON entirely. https://json5.org/

Generally looks good, but ugh, I dislike allowing single quotes. Allowing single quotes has close to zero ergonomic value but increases the number of ways to write the same fundamental thing. But that's a minor quibble. If everyone adopted this thing instead of legacy JSON, we'd be better-off.

Having two ways to quote is a useful feature, not just one way to do the same thing.

Javascript already has this, so allowing single quotes simplifies copypasting object literals, which is a common use case.

Re: TOML – Tom's Obvious, Minimal Language

#128
People keep confusing program configuration files and program stdin and are surprised that TOML is not a good fit for it.

If you are provisioning servers from a TOML files, you're doing it wrong. That's your program main input, not config.

If you have deeply nested values, chances are you are again confusing configuration vs main input.

JSON and CSV are great main input formats.

TOML is a great configuration format.

YAML and XML try to do both, and end up doing average on either, but being abused for all of them (looking at you Ansible and Solr).

So you should use each format for the correct purpose, as usual.

A config file looks like ~/.ssh/config or /etc/nginx/nginx.conf, not like ~/.ssh/authorized_keys or /etc/nginx/site-available/default.conf.

Just because we love to put a lot of data input in config folders (.config and /etc are full of input data) and call that configuration doesn't make it so.

How to know if something is configuration and something is input?

Conf data is usually only manually edited (authorized_keys changes with the life cycle of the program) and doesn't contain logic (default.conf if full of logic). Conf is also how the program is going to behave when performing its main task, the boostraping state, not the data used for it's main task (so not ip for provisioning servers, which is not meta, but the main course, or default.conf, which nginx uses to perform the main task). Conf rarely changes, main input often does. Conf is not piped or redirected to stdin.

Re: TOML – Tom's Obvious, Minimal Language

#129

I had tons of headaches trying to get toml to do what's trivial in Json (nested arrays of objects of arrays of ... etc). 1/10 would not try again. For very simple, hear "flat" config it checks out. But then, so does yaml or even ini files. Anything requiring composite types was just a nightmare. I'd even prefer xlm before using toml again.

toml really is best for mostly flat data. when your config grows more complex than that, i recommended you break it into multiple files and use directory structures or filenames to convey their relationship. or, of course, switch to a configuration format that is more well suited to deeply-nested data.

your comparison to yaml or ini is apt; toml's strength over yaml is syntax simplicity and toml is more-or-less a superset of ini (which itself is poorly-defined).

Re: TOML – Tom's Obvious, Minimal Language

#130
post #85

Earlier quoted context omitted.

JSON is too strict/simple This is why I like JSON! I have seen the horrors of XSLT and I’m never going back.

IMO it kind of sucks that you're not able to add comments to JSON easily. In TOML (or YAML) it's just as easy as prepending it with # at the beginning of the line.

> add comments to JSON easily

Simple, write comments in Morse code using spaces and tabs.

Post reply on HN