10 ms·
JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objec
by SPBS 3y ago
JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objects (being both hard to read and hard to write), due to a misguided attempt to avoid becoming JSON-like[1].
[1] https://github.com/toml-lang/toml/issues/516 https://github.com/toml-lang/toml/issues/516
- eviks 3y agostill won't be prefect, all those extra quotes are bad for a heavily used human readable configs format
- arp242 3y agoThat's already fixed; in the upcoming TOML 1.1 you can write: tbl = { hello = "world", } All the examples in the issue you linked should work. https://github.com/toml-lang/toml/pull/904 https://github.com/toml-lang/toml/pull/904
- bdudbdjsh 3y agopublished data standards having version is so wrong. now if you see "config in yaml" you know nothing, zero, nada, about the format because all versions are so different and everyone implemented the version at the time and didn't bother to mention version. not to mention you can use a dozen syntaxes for yaml/toml and each application may not understand them all. all this is so silly. we will stick with json and informal-ini forever one way or another.
- eviks 3y agoSince it's impossible to design anything great in tech on first attempt, what is the road to improvement without versions? (and mentioning version could be a requirement in a future version)
- arp242 3y agoIt's not ideal, I agree, but it solves real problems for people, so there's that. Many commonly-used standards today weren't created by a bunch of wise men in a room thinking how to bestow their wisdom upon the rest of us, they often originated in real-world applications, were refined over a period of time based pn real-world experience, and then became a standard. TOML is the same. I hope it will become an RFC some day. We just need to fix a few outstanding issues first. Most commonly used TOML parsers support 1.0; adding 1.1 support should be pretty easy as the changes aren't that large (I did it in the parser I maintain, and it's 10 lines of code or so that had to be changed, most of them quite trivial).
- Marazan 3y agoMy opinion is that having a version is fine buy only if a version field is built into the spec. Without that your config file is a boobytrap, with it everything is fine and your parsing libraries can even be backwards compatible.
- ruuda 3y agoAnd if you have to version it, Kelvin versioning is more appropriate for standards.
- isitmadeofglass 3y ago[dead]
- SPBS 3y agoThe is great news, thank you for your work on this.
- IshKebab 3y agoHow do you know which version you are using though?
- arp242 3y agoYou don't; you check the library or application's documentation. TOML went through some substantial changes in the past with 0.4, 0.5, and 1.0. As I mentioned in my other comment[1], it's not ideal, but it is what it is. I wouldn't be surprised if 1.1 would be the last version. Maybe there will be a 1.2 to clarify some things, but I wouldn't expect any further major changes. [1]: https://news.ycombinator.com/item?id=36020654 https://news.ycombinator.com/item?id=36020654
- IshKebab 3y ago> You don't Great. Very obvious.
- josephg 3y agoAs much as it pains me to say so, this is probably fine for configuration languages so long as they’re backwards compatible. Eg toml is used by rust’s cargo tool. Cargo can just say “hey Cargo.toml is parsed in toml version 1.1 format”.
- IshKebab 3y agoHow does your IDE and linter learn that? In fairness it's probably not too bad as long as everyone actually migrates to the newest version eventually... But that isn't guaranteed - look at YAML. Or even JSONC. VSCode has a hard-coded lists of which `.json` files are actually JSONC. Gross.
- afiori 3y agoYAML is way more complex and JSONC is not JSON 1.1
- pydry 3y agoI think this was partly what the pytoml author was alluding to when he slated the format: https://github.com/avakar/pytoml/issues/15#issuecomment-217739462 https://github.com/avakar/pytoml/issues/15#issuecomment-2177... Datetimes were clearly a mistake to include too. It took the M out of TOML.
- KronisLV 3y ago> JSON is basically perfect if it allowed trailing commas and comments. I agree, especially in regards to the comments, because sometimes the data itself isn't enough and additional human-readable context can be really useful! In that regard, JSON5 is a wonderful idea, even if sadly it isn't widespread: https://json5.org/ https://json5.org/ It also supports the trailing commas and overall just feels like what JSON should be, to make it better without overcomplicating it.
- nikeee 3y agoI like the idea of JSON5, but it allows a bit too much in my opinion. For example, why add the single quote? Why hexadecimal identifiers?
- veidr 3y agoJSON is trash and should never be used in any human-interfacing context, so I'm super skeptical that there's any utility in trying to fix it; that would just delay its demise, to the detriment of humankind. But if you did want to fix JSON, the yes, trailing commas and comments are the absolute minimum bar, but single quote is actually probably the the third absolute must-fix. The reason is just that so much JavaScript tooling is now configured to autoformat code (including the JSON bits) to swap " to ', thanks in large part to Prettier (which also should almost never be used, sigh, but that's a topic for another HN bikeshed...) hexadecimal identifiers, yeah, nah
- NoahKAndrews 3y agoPrettier defaults to double quotes. I'm curious what you have against Prettier.
- evntdrvn 3y agoYou might be interested to check out JSONC and JWCC/HuJSON https://nigeltao.github.io/blog/2021/json-with-commas-comments.html https://nigeltao.github.io/blog/2021/json-with-commas-commen... https://github.com/tailscale/hujson https://github.com/tailscale/hujson
- hellcow 3y agoMulti-line strings are another weakness. Sometimes you don’t\nwant\nto\nwrite\nthis\nway.
- wewxjfq 3y agoThe problem with comments in configuration files is that they don't survive a `load -> native object -> save` round-trip.
- jen20 3y agoThat sounds more like a problem with deserializing configuration instead of parsing.
- peteradio 3y agoComments lie, I think it would make sense to destroy them in load to native.
- riffraff 3y agoShould a configuration language be a serialization language? I'm unconvinced.
- rwmj 3y agoAugeas solves this for many config file formats: http://augeas.net/ http://augeas.net/
- ithkuil 3y agoI played around with "format preserving" edits of a few text formats, including nested formats (a JSON inside a TOML inside a YAML etc) https://github.com/mkmik/knot8 https://github.com/mkmik/knot8
- ilyt 3y agoThey could if you parsed it into syntax tree wit some methods to access keys instead of parsing into native struct. I think I saw YAML parser doing it...
- 3np 3y agoAre you talking about https://github.com/toml-lang/toml/pull/904 https://github.com/toml-lang/toml/pull/904 which is merged for 1.1, or something else?
- bdhcuidbebe 3y agoThe poroblem now becomes incompatibility about what a toml document is.
- r3trohack3r 3y agoIf you parse JSON as YAML you can add comments! YAML is a proper superset of JSON.
- slondr 3y agoNot really. https://stackoverflow.com/questions/21584985/what-valid-json-files-are-not-valid-yaml-1-1-files https://stackoverflow.com/questions/21584985/what-valid-json...
- ohazi 3y ago> JSON is basically perfect Until you realize you can't actually store real integers because every number in js is a float...
- data-ottawa 3y agoYou can store the first 2^53 integers with either sign, and if you need accurate integer values beyond that size you can stringify them and parse as big ints. It’s not ideal, but 2^64 integers is also finite.
- gliptic 3y agoJSON allows you to store arbitrarily large integers/floats. It's only in JS this is a problem, not if you use JSON in languages that support larger (than 54-bit) integers.
- the_gipsy 3y agoThat's the freedom of unspecified behavior.
- marcosdumay 3y agoAs long as the same person is on both sides of a communication channel, he has total freedom on what to say and will understand it flawlessly! That's what standards are for, isn't it?
- deleted 3y ago[deleted]
- no_wizard 3y agoAnnoyingly, it also doesn't support BigInt, which would alleviate this problem in JS as well
- Simran-B 3y ago
- chubot 3y agoI kinda agree, but I also think then you want unquoted keys {name: "value"} And then maybe 123_456 syntax It's a slippery slope ... pretty soon it's hard to write a JSON parser, and there are more bugs The trailing comma one is trivial, I'll grant that
- marcosdumay 3y agoTrailing commas a very highly impactful to the users, and trivial to the language writers. The 123_456 syntax comes close to that, but is much less impactful. None of those will make the language hard to parse.
- Spivak 3y agoAs much as I think it's annoying I think no trailing commas enforces good coding hygiene and basically forces you to use a real encoder rather than as hoc string manipulations.
- rand_flip_bit 3y agoThis is such a bad take
- Spivak 3y agoCare to like, elaborate? Stopping people from doing brittle stuff like print("{") for elem in list: print('"key": "value",') print("}") seems like immediate worth.
- alwaysbeconsing 3y agoThat's not a very big hurdle to overcome, though: print("{") contents = "" for elem in list: contents += '"key": "value",' print(contents[:-1]) print("}")
- marcosdumay 3y ago
- rwmj 3y agoAnd if you fixed numbers so you could use 64 bit integers.
- miki123211 3y agoMaybe you could even skip the commas entirely (or threat newlines as commas if possible?) That, along with unquoted keys, would make JSON perfect for me. In such a hypothetical format, eliminating nulls entirely should Also be considered, the difference between a missing key (undefined) and a null value is significant in JS, but other (particularly statically-typed) languages struggle with differentiating those two cases, and this leads to `serialize(deserialize(a))` representing a different document than `a`.
- s3v 3y agoEverything is perfect except for the reasons it isn't.
- wkdneidbwf 3y agohaha, this exact thing is my biggest gripe with toml edit: just found https://github.com/toml-lang/toml/discussions/915#discussioncomment-4776440 https://github.com/toml-lang/toml/discussions/915#discussion..., super happy to be able to rest this out early
- burntsushi 3y agoGood thing TOML was never intended to be a JSON replacement.
- bccdee 3y agoIt kills me just how close JSON was to getting it right. If JSON had been JSON5 [1] instead, YAML and TOML probably wouldn't exist. [1]: https://json5.org/ https://json5.org/
- atoav 3y agoI think JSON syntax is more prone to user syntax errors. And we are talking about syntax errors by the kind of user that neither knows what a "syntax error" nor "JSON" is. Hence the "O" in "TOML" ("Obvious"). And this is the use case for TOML, simple user facing configuration that they are very likely to just get right. JSON is fine for more intricate data structures or very complex configuration, but if you just need them to enter a few numbers and booleans it is overkill.
- musicale 3y agoI kind of like the text property list format from NeXTSTEP, used in GNUstep and (formerly) in macOS. Apple's XML plist format seems like a mistake, though maybe the newer JSON format is OK. > JSON is basically perfect if it allowed trailing commas and comments Apparently Apple actually supports JSON5, an extended JSON based on ES5 that allows trailing commas, comments, and (my favorite!) unquoted key names, among other convenient features.
- ojosilva 3y agoI find that YAML can be, if stripped down to the nice parts, a delightful config file structure. Here's the toml.io example in perfectly legal YAML but using only YAML's nicer, JSON-like, compatibility grammar: title: "TOML Example" owner: { name: "Tom Preston-Werner", dob: 1979-05-27 07:32:00 -08:00 } database: { enabled: true, ports: [8000, 8001, 8002], data: [ ["delta", "phi"], [3.14] ], temp_targets: { cpu: 79.5, case: 72.0 } } servers: { alpha: { ip: "10.0.0.1", role: "frontend" }, beta: { ip: "10.0.0.2", role: "backend" }, } If I were on the YAML board (?) I would push this or a similar subset (JAML? DUML? DUMBL?) to be implemented by parsers in every language: yaml.parse(yamlString, { jamlMode: true }). But it already works today anyway if you stick to the format. And that's what I use for my apps. Multi-line strings in YAML are also very similar to TOML and you can ignore all different character mixups and stick to '|' (w/ newlines) and '"' (no newlines). # same as " hello world! " str1: " hello world! " # same as "apples\noranges\n" str2: | apples oranges Most numeric TOML examples work too, minus a few bells and whistles like numeric separators '_': # integers int1: +99 int2: 42 int3: 0 int4: -17 # hexadecimal with prefix `0x` hex1: 0xDEADBEEF hex2: 0xdeadbeef # octal with prefix `0o` oct1: 0o01234567 oct2: 0o755 # fractional float1: +1.0 float2: 3.1415 float3: -0.01 # exponent float4: 5e+22 float5: 1e06 float6: -2E-2 # both float7: 6.626e-34 # infinity infinite1: .inf # positive infinity infinite2: +.inf # positive infinity infinite3: -.inf # negative infinity # not a number not1: .nan