5 ms·

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.

rascul 3y ago
YAML is more complex and difficult to write than TOML.
OtomotO 3y ago
Yaml is incredibly complex. KISS
MrJohz 3y ago
YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load. The other big issue is that, by default, it allows relatively unrestricted code execution in many environments. If a user is ever able to submit data that is interpreted by a YAML parser, they can run arbitrary code, and potentially even commands. The fixes for these are both fairly well known (always quote strings and keys, use safe_load or an equivalent API), but it's very easy to make a mistake. TOML, by contrast, is much simpler - strings are strings are strings, they must always be quoted but other than that behave pretty much as expected. Similarly, there is no mechanism by which a TOML file can instruct the parser to execute arbitrary code as part of deserialisation, which makes it (a) a lot simpler, and (b) a lot safer.
- daveevad 3y ago
  Someone at work recently got bit by unexpected YAML parsing a git commit hash that contained a substring which was a valid number in scientific notation (IIRC 5e38031).
  - jerpint 3y ago
    Ouch
- Gare 3y ago
  > YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load. This was fixed in YAML 1.2, but the problem is that almost nobody uses (and there is patchy support for) it.
- tedivm 3y ago
  The vast, vast majority of issues with YAML can be solved by quoting all strings. Then a lot of the type inference magic goes away.
- AceJohnny2 3y ago
  YAML is interesting, because at first glance it looks like a pretty convenient, human-readable syntax, it's got lists, dicts/mappings, strings, numbers, booleans... simple enough for 90% of the use-cases, and focusing on "human-readable, right? But look at little deeper and one uncovers some horrors. In particular, the plethora of boolean values... here let me just grab the regex from the spec [1]: y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF At that point why limit yourself to just the English language? Then there's the language-specific types or, as YAML calls them, "local tags". The stuff preceded by `!` like !!map { ? !<tag:yaml.org,2002:str> "foo" : !<!bar> "baz" } At that point, you've exceeded the scope of "human-readable". I'll admit there are some other, er, "complications" that I actually like. In particular, anchors (`&FOO`) and aliases/references (`*FOO`) [2] make it possible to describe arbitrary graphs, and I find it very useful to factorizing blocks. Also, "folding" [3] text, which allows you to spread value/text across multiple lines for readability, while respecting the surrounding indentation, is neat. [1] https://yaml.org/type/bool.html https://yaml.org/type/bool.html [2] https://yaml.org/spec/1.0/#syntax-anchor https://yaml.org/spec/1.0/#syntax-anchor [3] https://yaml.org/spec/1.0/#id2566944 https://yaml.org/spec/1.0/#id2566944
  - Spivak 3y ago
    YAML 1.2 fixed the boolean thing. Language tags can get weird but they're ultimately just additional types implemented by your yaml parser you should basically always turn off/not turn on unless you know you want it. You can serialize classes in your language without it. Tags are really good for readability if you use them thoughtfully value: !!binary base64string # ordered map value: !!omap a: 123 b: 455 The reason that example is so ugly is it's using the "complex mapping key" syntax which is unbelievably ugly but if you're using objects as keys in your map you abandoned sanity long ago.
rayrrr 3y ago
YAML is not reliably machine-readable, nor was it designed to be. TOML was designed to be machine-readable, but otherwise fulfilling a similar use case as YAML.
- danmur 3y ago
  I think YAML was designed to machine readable. What would you do with it otherwise? Nobody's writing poetry in it (that I know of)
danmur 3y ago
I assume neither of us has experienced these YAML bites that others have :). I don't mind TOML but I don't find it either intuitive or obvious. The syntax for how nested things are flattened I just find really hard to read and write. It's fine though, not that big a deal.
polski-g 3y ago
Yaml has terrible type enforcement. If you have "no" as the value, sometimes it will be a boolean and sometimes a string.

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.

rascul 3y ago

YAML is more complex and difficult to write than TOML.

OtomotO 3y ago

Yaml is incredibly complex. KISS

MrJohz 3y ago

YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load. The other big issue is that, by default, it allows relatively unrestricted code execution in many environments. If a user is ever able to submit data that is interpreted by a YAML parser, they can run arbitrary code, and potentially even commands. The fixes for these are both fairly well known (always quote strings and keys, use safe_load or an equivalent API), but it's very easy to make a mistake. TOML, by contrast, is much simpler - strings are strings are strings, they must always be quoted but other than that behave pretty much as expected. Similarly, there is no mechanism by which a TOML file can instruct the parser to execute arbitrary code as part of deserialisation, which makes it (a) a lot simpler, and (b) a lot safer.

daveevad 3y ago
Someone at work recently got bit by unexpected YAML parsing a git commit hash that contained a substring which was a valid number in scientific notation (IIRC 5e38031).
- jerpint 3y ago
  Ouch
Gare 3y ago
> YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load. This was fixed in YAML 1.2, but the problem is that almost nobody uses (and there is patchy support for) it.
tedivm 3y ago
The vast, vast majority of issues with YAML can be solved by quoting all strings. Then a lot of the type inference magic goes away.
AceJohnny2 3y ago
YAML is interesting, because at first glance it looks like a pretty convenient, human-readable syntax, it's got lists, dicts/mappings, strings, numbers, booleans... simple enough for 90% of the use-cases, and focusing on "human-readable, right? But look at little deeper and one uncovers some horrors. In particular, the plethora of boolean values... here let me just grab the regex from the spec [1]: y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF At that point why limit yourself to just the English language? Then there's the language-specific types or, as YAML calls them, "local tags". The stuff preceded by `!` like !!map { ? !<tag:yaml.org,2002:str> "foo" : !<!bar> "baz" } At that point, you've exceeded the scope of "human-readable". I'll admit there are some other, er, "complications" that I actually like. In particular, anchors (`&FOO`) and aliases/references (`*FOO`) [2] make it possible to describe arbitrary graphs, and I find it very useful to factorizing blocks. Also, "folding" [3] text, which allows you to spread value/text across multiple lines for readability, while respecting the surrounding indentation, is neat. [1] https://yaml.org/type/bool.html https://yaml.org/type/bool.html [2] https://yaml.org/spec/1.0/#syntax-anchor https://yaml.org/spec/1.0/#syntax-anchor [3] https://yaml.org/spec/1.0/#id2566944 https://yaml.org/spec/1.0/#id2566944
- Spivak 3y ago
  YAML 1.2 fixed the boolean thing. Language tags can get weird but they're ultimately just additional types implemented by your yaml parser you should basically always turn off/not turn on unless you know you want it. You can serialize classes in your language without it. Tags are really good for readability if you use them thoughtfully value: !!binary base64string # ordered map value: !!omap a: 123 b: 455 The reason that example is so ugly is it's using the "complex mapping key" syntax which is unbelievably ugly but if you're using objects as keys in your map you abandoned sanity long ago.

rayrrr 3y ago

YAML is not reliably machine-readable, nor was it designed to be. TOML was designed to be machine-readable, but otherwise fulfilling a similar use case as YAML.

danmur 3y ago
I think YAML was designed to machine readable. What would you do with it otherwise? Nobody's writing poetry in it (that I know of)

danmur 3y ago

I assume neither of us has experienced these YAML bites that others have :). I don't mind TOML but I don't find it either intuitive or obvious. The syntax for how nested things are flattened I just find really hard to read and write. It's fine though, not that big a deal.

polski-g 3y ago

Yaml has terrible type enforcement. If you have "no" as the value, sometimes it will be a boolean and sometimes a string.