Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TOML: Tom's Obvious Minimal Language

toml.io

Post reply on HN
Print view View original

171–180 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#171

Post by 3193528104 »

crabbone wrote: post #164

It's another junk format in the sea of junk formats. It sucks for describing data, its structure is too primitive, has wrong primitives, doesn't allow extension and has no mitigations for that. Essentially, it's used because it's simple to parse and there are existing parsers. But the problems it creates are very complicated. So, here's one example of a popular use-case: pyproject.toml. I mean, PyPA aren't the bright…

> I mean, PyPA aren't the brightest minds around

You don't need to be an asshole to get your message across.

Re: TOML: Tom's Obvious Minimal Language

#172

Post by throwawaaarrgh »

TOML is, indeed, a human friendly config format. Whereas INI is a simple config format.

YAML/JSON/CSV/XML/etc are not config formats at all. They are data serialization formats. If you don't know the difference, you probably didn't get a CS degree, or read or understand the specs.

Config formats should be tailored to the application, because the entire point of a config file is to make it easy for a human to configure one specific application. That's why there are 100 different config file formats for old UNIX programs. For each one, it's vastly easier to use that one config format for that one application, than it would be to force some arbitrary data serialization format to represent what the human really wanted the program to do.

TOML is better than YAML or INI for a config file, but what's best is rolling your own format. It literally leads to better outcomes. The user can express what they want faster, easier, clearer, and the application doesn't have to struggle with alternate implementations of the spec for some poorly defined data serialization format.

Re: TOML: Tom's Obvious Minimal Language

#173

Post by theknocker »

throwawaaarrgh wrote: post #172

TOML is, indeed, a human friendly config format. Whereas INI is a simple config format. YAML/JSON/CSV/XML/etc are not config formats at all. They are data serialization formats. If you don't know the difference, you probably didn't get a CS degree, or read or understand the specs. Config formats should be tailored to the application, because the entire point of a config file is to make it easy for a human to configur…

[dead]

Re: TOML: Tom's Obvious Minimal Language

#174

Post by tedivm »

MrJohz wrote: post #154
Simran-B wrote: post #144

Earlier quoted context omitted.

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.

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 environmen…

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.

Re: TOML: Tom's Obvious Minimal Language

#175

Post by Guthur »

TylerE wrote: post #19
Guthur wrote: post #4

Earlier quoted context omitted.

Well that would be null right? an absence of the thing.

Null is one way to represent such a value, but it’s hardly the only. Option-style algebraic types are another, and more or less strictly superior if working in a language with first class support for such, because they force you to explicitly handle the null/None/Empty/whatever case if you’re doing something with it that could fail (basically anything besides assignment or passing it along).

Seems beyond the simplicity TOML was aiming for. Absence is absence in the file, in your programming language you can wrap in whatever trickier you like or is relevant.

Re: TOML: Tom's Obvious Minimal Language

#176

Post by debugnik »

riffraff wrote: post #67
bonzini wrote: post #36

Earlier quoted context omitted.

Note that now you have "the Norway problem" instead. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ There's a whole spectrum of config formats including JSON, JSON5, strict YAML, YAML. It's quite messy.

The norway problem is not a problem if you use yaml 1.2. Which is 14 years old. EDIT: this sounded adversarial which was not my intention. Plenty of libraries do not support 1.2 which sucks, I just meant that it's something solved in theory a long time ago.

Could you explain further? The link contradicts this:

> The most tragic aspect of this bug, however, is that it is intended behavior according to the YAML 1.2 specification. The real fix requires explicitly disregarding the spec - which is why most YAML parsers have it.

Re: TOML: Tom's Obvious Minimal Language

#177

Post by majewsky »

throwawaaarrgh wrote: post #172

TOML is, indeed, a human friendly config format. Whereas INI is a simple config format. YAML/JSON/CSV/XML/etc are not config formats at all. They are data serialization formats. If you don't know the difference, you probably didn't get a CS degree, or read or understand the specs. Config formats should be tailored to the application, because the entire point of a config file is to make it easy for a human to configur…

Where do you draw the line between config file format and data serialization format? The first paragraph of the TOML spec says:

> TOML is designed to map unambiguously to a hash table.

Sounds like a data serialization format to me. Besides the obvious differences in design and stylistic choices, it only really differs from JSON or YAML in that the top-level object of the data structure must be an object. If this type of constraint is what makes it a config file format, I am going to change the world with my revolutionary new config file format "JSON, but the first byte must be {".

As another evidence for the blurriness of this line: Cargo uses TOML for its config file (Cargo.toml) which matches the usage that you describe. But then it also uses TOML for the serialization of its internal locking data structure in Cargo.lock, which is a file that humans are specifically not told to edit directly because it just contains serialized data. It just so happens to use TOML, probably because they already had a parser for that available at the time.

> TOML is better than YAML or INI for a config file, but what's best is rolling your own format. It literally leads to better outcomes.

Disadvantages of rolling your own format:

- You now have to write your own parser, which costs at least a bit of time and is going to be more prone to bugs than a widely-used deserialization library like Serde. I see that you dunk on data serialization formats being "poorly defined", but if the popular formats are poorly defined, then certainly the average tool developer is not going to do a better job when they actually want to implement the tool and not the parsing for a config file format.

- Users have to learn the format, and have to mentally switch between formats for each application. I just hate how every homegrown config format uses slightly different syntax, esp. which character starts a comment. With `config.yaml` or `config.toml`, I don't have to guess.

- If the config file is YAML or TOML, I immediately have some basic syntax highlighting in my editor.

Re: TOML: Tom's Obvious Minimal Language

#178

Post by somewhereoutth »

josephg wrote: post #133
somewhereoutth wrote: post #118

Earlier quoted context omitted.

But JSON is strings. So 123.4 is essentially "123.4" but with the indication that it is supposed to be semantically a numerical value.

Right. I want to see an indication of what sort of numerical value it is. Big integers interpreted as floats lose precision. And floats decoded as integers truncate anything after the decimal place. JSON makes it way too easy to get this stuff wrong when decoding.

If it has a decimal point then it is a decimal. And if it doesn't (or if it only has zeros after the point) then it's an integer. JSON is absolutely unambiguous as to the actual numerical value - how badly that gets translated into the decoding language is entirely on that language.

Re: TOML: Tom's Obvious Minimal Language

#179

Post by detaro »

debugnik wrote: post #176
riffraff wrote: post #67

Earlier quoted context omitted.

The norway problem is not a problem if you use yaml 1.2. Which is 14 years old. EDIT: this sounded adversarial which was not my intention. Plenty of libraries do not support 1.2 which sucks, I just meant that it's something solved in theory a long time ago.

Could you explain further? The link contradicts this: > The most tragic aspect of this bug, however, is that it is intended behavior according to the YAML 1.2 specification. The real fix requires explicitly disregarding the spec - which is why most YAML parsers have it.

The link is wrong. YAML 1.2 fixed this.

Re: TOML: Tom's Obvious Minimal Language

#180

Post by Rapzid »

enriquto wrote: post #155

Graybeard opinion: all of toml, yaml, xml, json, kdl, etc., are ridiculously over-engineered for simple configuration files. You can nearly always fulfill all of your needs with a simple two-column text file of key=value pairs that can be parsed by a trivial call to fscanf(3) or whatever your laguage supports (yes, even correctly discarding comments). The world would be a better place if people just gron'd their json…

How do you handle data structures in your key/value world? Parse it out of some adhoc key string schema?
Post reply on HN