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.
TOML – Tom's Obvious, Minimal Language
121–130 of 163 posts
Re: TOML – Tom's Obvious, Minimal Language
#122Earlier 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.…
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
#123Earlier 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.
Re: TOML – Tom's Obvious, Minimal Language
#124TOML 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…
TOML is for config, config that users edit by hand, not input.
Re: TOML – Tom's Obvious, Minimal Language
#125I 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.
Re: TOML – Tom's Obvious, Minimal Language
#126Earlier 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.
Re: TOML – Tom's Obvious, Minimal Language
#127Earlier 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.
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
#128If 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
#129I 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.
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
#130Earlier 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.
Simple, write comments in Morse code using spaces and tabs.