3 ms·

Like YAML, it's only better in the simple case where everything is top-level and there's only one level of nesting. Once you want to have arrays of nested obje

Like YAML, it's only better in the simple case where everything is top-level and there's only one level of nesting. Once you want to have arrays of nested objects or objects with arrays, I immediately wish I was just reading JSON so I knew where I was in the tree. And for that reason, I don't think it's a full contender. I want an answer for the hard cases like nested data, not just another way to write the simple cases which is what TOML is. For example, [[a.b]] x = 1 [a] y = 2 Versus: { "a": { "b": [ { "x": 1 } ], "y": 2 } } It's easy to complain that the latter is noisier. But that's nothing compared to being clear.

okanat 2y ago
This is also the reason I prefer XML to JSON when things really got complex. XML is verbose but it is very readable on long form. I wish Rust actually used JSON or XML as Cargo file format.
- Alex-Programs 2y ago
  I think it works quite nicely in Cargo as you don't generally need much nesting, but anything with depth should use JSON. It's the perfect format for clearly displaying hierarchy.
  - okanat 2y ago
    It works only for trivial projects that are compiled in a roughly up-to-date and popular environment. Custom distros, vendored forks, closed-source software, firmware projects etc. all end up with hairy Cargo files. A systems language should recognize handling complexity gradually is a part of one of its use cases.
zahlman 2y ago
It's not made explicit in the documentation, but TOML is very nearly a superset of JSON - just using `=` to separate key-value pairs instead of `:`, and requiring top-level names to be given explicitly, and requiring the "inline" bits to be on a single line. In TOML, your example can equivalently be: a = { b = [ { x = 1 } ], y = 2 } (And yes, that can be the entire document; you can have an inline table before the first table header.) Of course, this doesn't help if you want the top level to be an "array" rather than an "object" (in JSON parlance), or if you want the entire document to represent a single primitive value. But these uses are discouraged at best anyway. But really the goal of TOML is to highlight the location of important parts of the deserialized tree structure (hence the ability to use arbitrary long dotted paths in table headers) rather than the structure itself. It's IMO a beautiful implementation of the idea "flat is better than nested" from the Zen of Python, and it neatly sidesteps an issue I asked about many years ago on Stack Overflow (https://stackoverflow.com/questions/4372229 https://stackoverflow.com/questions/4372229 - the question was rightfully closed, as this sort of discussion doesn't fit the Q&A format; but it made sense to ask at the time). I don't know if a direct comparison of TOML to YAML is fair. Among other differences, the standard way to parse YAML in Python involves a third-party library that brings in a ~2.5 MB compiled C library. Every TOML implementation I encountered - including the one that made it into the standard library - is pure Python.
- lifthrasiir 2y ago
  > But these uses are discouraged at best anyway. To my knowledge, such uses were discouraged only because of a security issue from evaluating a JSON string as a JavaScript code and not via something like JSON.parse.
  - int_19h 2y ago
    Given that TOML is intended primarily as a format for configs, a config where the root value is an array or a primitive value is hardly a relevant scenario.
arp242 2y ago
Your TOML is rather convoluted, a more normal way to write it would be: [a] b = [{x = 1}] y = 2 Or alternatively: a.b = [{x = 1}] a.y = 2 Some parsers allow newlines in TOML inline tables, so you can do: a = { b = [{x = 1}], y = 2, } That's supposed to be in the next TOML standard, but that seems indefinitely stalled as the (only) maintainer has seemingly lost interest and there hasn't been any movement for a long time.
- deleted 2y ago
  [deleted]
- michaelcampbell 2y ago
  > Your TOML is rather convoluted, a more normal way to write it would be Anecdata, granted, but I've seen a lot of TOML written exactly like the "convoluted" example, and none like your more spread out version.

okanat 2y ago

This is also the reason I prefer XML to JSON when things really got complex. XML is verbose but it is very readable on long form. I wish Rust actually used JSON or XML as Cargo file format.

Alex-Programs 2y ago
I think it works quite nicely in Cargo as you don't generally need much nesting, but anything with depth should use JSON. It's the perfect format for clearly displaying hierarchy.
- okanat 2y ago
  It works only for trivial projects that are compiled in a roughly up-to-date and popular environment. Custom distros, vendored forks, closed-source software, firmware projects etc. all end up with hairy Cargo files. A systems language should recognize handling complexity gradually is a part of one of its use cases.

zahlman 2y ago

It's not made explicit in the documentation, but TOML is very nearly a superset of JSON - just using `=` to separate key-value pairs instead of `:`, and requiring top-level names to be given explicitly, and requiring the "inline" bits to be on a single line. In TOML, your example can equivalently be: a = { b = [ { x = 1 } ], y = 2 } (And yes, that can be the entire document; you can have an inline table before the first table header.) Of course, this doesn't help if you want the top level to be an "array" rather than an "object" (in JSON parlance), or if you want the entire document to represent a single primitive value. But these uses are discouraged at best anyway. But really the goal of TOML is to highlight the location of important parts of the deserialized tree structure (hence the ability to use arbitrary long dotted paths in table headers) rather than the structure itself. It's IMO a beautiful implementation of the idea "flat is better than nested" from the Zen of Python, and it neatly sidesteps an issue I asked about many years ago on Stack Overflow (https://stackoverflow.com/questions/4372229 https://stackoverflow.com/questions/4372229 - the question was rightfully closed, as this sort of discussion doesn't fit the Q&A format; but it made sense to ask at the time). I don't know if a direct comparison of TOML to YAML is fair. Among other differences, the standard way to parse YAML in Python involves a third-party library that brings in a ~2.5 MB compiled C library. Every TOML implementation I encountered - including the one that made it into the standard library - is pure Python.

lifthrasiir 2y ago
> But these uses are discouraged at best anyway. To my knowledge, such uses were discouraged only because of a security issue from evaluating a JSON string as a JavaScript code and not via something like JSON.parse.
- int_19h 2y ago
  Given that TOML is intended primarily as a format for configs, a config where the root value is an array or a primitive value is hardly a relevant scenario.

arp242 2y ago

Your TOML is rather convoluted, a more normal way to write it would be: [a] b = [{x = 1}] y = 2 Or alternatively: a.b = [{x = 1}] a.y = 2 Some parsers allow newlines in TOML inline tables, so you can do: a = { b = [{x = 1}], y = 2, } That's supposed to be in the next TOML standard, but that seems indefinitely stalled as the (only) maintainer has seemingly lost interest and there hasn't been any movement for a long time.

deleted 2y ago
[deleted]
michaelcampbell 2y ago
> Your TOML is rather convoluted, a more normal way to write it would be Anecdata, granted, but I've seen a lot of TOML written exactly like the "convoluted" example, and none like your more spread out version.