Live data from Hacker News

TOML: Tom's Obvious Minimal Language

toml.io

101–110 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#101

I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. JSON6 proposal [1] supports all of this, except (4). Unfortunately it also supports more and make the spec a bit too complex for my taste (JSON has a compact spec; any extension should honor this). Same issue with JSON…

I like Google's Jsonnet [1], which has all of this except for 4.

Jsonnet is quite mature, with fairly wide language adoption, and has the benefit of supporting expressions, including conditionals, arithmetic, as well as being able to define reusable blocks inside function definitions or external files.

It's not suitable as a serialization format, but great for config. It's popular in some circles, but I'm sad that it has not reached wider adoption.

[1] https://jsonnet.org/

Re: TOML: Tom's Obvious Minimal Language

#102
post #63
post #10

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

> JSON is basically perfect Until you realize you can't actually store real integers because every number in js is a float...

If both sides are using a language with integer types, this is a non-issue. JSON does not prescribe the number types in use, so the implementations may just say that the field contains 64-bit integers, and just parse them to and from the usual int64 type of their language. It is also legal for JSON parsers to parse numeric literals into an arbitrary-precision decimal type instead of IEEE 574 floats.

Re: TOML: Tom's Obvious Minimal Language

#103
I use TOML and JSON for everything. I like them both quite a bit. TOML gets a lot of criticism for not being JSON and JSON gets a lot of criticism for... not being entirely fit for it's stated purpose. However, they're both fantastic if you use them for what they're good at: TOML for human readable configurations that you expect a user to modify, JSON for representing data that a machine will read all of the time but that you want the user to be able to look at and grasp. I don't think either of them really need to grow to be good at both, they're fine as they are, just pick the right tool for the job.

Re: TOML: Tom's Obvious Minimal Language

#104
post #16

Earlier quoted context omitted.

That'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

published 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 infor…

My 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.

Re: TOML: Tom's Obvious Minimal Language

#105
post #63

Earlier quoted context omitted.

> JSON is basically perfect Until you realize you can't actually store real integers because every number in js is a float...

You can store arbitrary precision numbers in JSON. The spec explicitly doesn't lock you into floats or any other specific number format.

Only if you are both sides of the transmission. If you're sending JSON to code you didn't write you will eventually get bitten by software lossy re-encoding. Lots of places use strings for this reason.

It's like API's that mess up the semantics of PUT/GET so implementing idempotency is extra annoying.

Re: TOML: Tom's Obvious Minimal Language

#106
post #66

Earlier quoted context omitted.

I 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

Trailing 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.

As 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.

Re: TOML: Tom's Obvious Minimal Language

#107
post #63
post #10

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

> JSON is basically perfect Until you realize you can't actually store real integers because every number in js is a float...

Except JSON can't even serialize all js numbers when it comes to NaN or infinity

Re: TOML: Tom's Obvious Minimal Language

#108

Earlier quoted context omitted.

Let me introduce you to our lord and savior: YAML. ;)

Ah yes, the language where a string can magically become a boolean and cause an error. And you can never be sure what is legal because of so many changes in parsing legality between versions. Yaml is one of the worst config languages.

Prior to YAML 1.2, unquoted numeric values containing : were interpreted as base 60, a common trip-up for Docker Compose port mappings. The intent was to make it easier to write times, i.e., 2:00 == 120.

Re: TOML: Tom's Obvious Minimal Language

#109
post #106

Earlier quoted context omitted.

Trailing 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.

As 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.

This is such a bad take

Re: TOML: Tom's Obvious Minimal Language

#110

Funny thing: TOML author/inventor calls it a mistake: > TOML is a bad file format. It looks good at first glance, and for really really trivial things it is probably good. But once I started using it and the configuration schema became more complex, I found the syntax ugly and hard to read. > I personally abandoned TOML and as such, I'm not planning on adding any new features > If you're still reading, I'd like to pu…

Tom (aka mojombo) is the founder of GitHub. https://github.com/mojombo
Post reply on HN