Live data from Hacker News

Toml: Tom's Obvious, Minimal Language

github.com

91–100 of 204 posts

Re: Toml: Tom's Obvious, Minimal Language

#91
post #37
post #21

Does anyone know why such a "joke proposal" (as stated by the author itself) was chosen for pretty significant projects like pip and cargo? (edit: I tried to say it began as something small and personal) (Well, I guess there's not that much to win/lose in the area of config languages, but still) (Also, I think it works pretty well, so this is not to downplay TOML!)

There's no one clear place to point to about how the decision was made for Cargo, but some nuggets have been left by authors [1]. The gist seems to be that JSON (and YAML, per that comment) was considered a poor format to author and maintain a config file in, and YAML had no lib in Rust and there was no appetite for anyone to write one. Pip's choice was made for them in the form of PEP 518 [2]. The authors of PEP 518…

I was one of the supporters of TOML back when this decision was made. I might have been the first one to suggest it, but I don't remember exactly.

Basically, I wanted something that was (1) simple, (2) terse, (3) supported comments, and (4) supported recursive data structures. Requirement (1) eliminated YAML, requirement (2) eliminated XML, requirement (3) eliminated JSON, and requirement (4) eliminated INI. Of the remaining formats, TOML seemed to be the most popular and had the most traction, so I went with that.

Re: Toml: Tom's Obvious, Minimal Language

#92
post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

Re: Toml: Tom's Obvious, Minimal Language

#93

> Whitespace means tab (0x09) or space (0x20). > Newline means LF (0x0A) or CRLF (0x0D0A). Complicating things from the start. Not a good sign.

Well some (many, actually) people use Windows too, and some prefer tabs and some prefer spaces; I can’t see why this is a problem?

A language for configs is different from a data interchange language: the former is intended to be written and edited by humans.

See https://arp242.net/weblog/json_as_configuration_files-_pleas...

Re: Toml: Tom's Obvious, Minimal Language

#94
post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

A killer feature of TOML compared to JSON is that it allows comments. A config file without comments and examples ain't great. I found the double square bracket syntax useful and understandable. Agreed it's not obviously .INI or perfectly elegant but it certainly works and has its use-cases. Anyways, thank you @mojombo!

> I found the double square bracket syntax useful and understandable

Really? I had kind of the inverse reaction to it. Indeed useful, but definitely not understandable

Re: Toml: Tom's Obvious, Minimal Language

#95
post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

Hey Tom, I just wanted to say thank you real quick. We use TOML in [Habitat]( https://github.com/habitat-sh/habitat ) to define default and overridable configuration. It's super easy and expressive. The [Habitat Core Plans]( https://github.com/habitat-sh/core-plans ) have quite a few examples about how it gets used in the project. If you are looking for examples of larger configuration files with .toml, then that mig…

[deleted]

Re: Toml: Tom's Obvious, Minimal Language

#96
post #55

Earlier quoted context omitted.

I'm a pretty big fan of TOML, though I've mostly only used it for Cargo. What are the limitations for large complex configs, and do you think there's currently a better configuration format for them? Feel free to link elsewhere if there's a canonical location for this discussion.

The limitations are mainly around nested arrays of tables. As has been mentioned here already, the [[array-of-tables]] syntax that currently allows this can be super confusing, and is definitely the worst part of TOML right now. Even so, you can often work around this weakness by reworking your config file to pick up on a specific naming scheme (perhaps every "server-*" table is interpreted as a member of an array) o…

> The limitations are mainly around nested arrays of tables. As has been mentioned here already, the [[array-of-tables]] syntax that currently allows this can be super confusing, and is definitely the worst part of TOML right now.

Good to know this is recognized. Looking forward to a better syntax to an indeed difficult problem

Re: Toml: Tom's Obvious, Minimal Language

#97
post #84

Earlier quoted context omitted.

Hi Tom. Dave here. I like a lot of the features in TOML, but I'm curious, can I have a pony? (Folks downvoting, PLEASE JUST LET PEOPLE HAVE JOKES EVERY NOW AND THEN)

You aren't going to change what people around here like. And complaining about downvotes usually just attracts more. If you think that your brand of funny is worth braving people's disapproval, do it knowing what the reaction is going to be. If you don't like people disapproving, then go elsewhere, or engage here in a way that people prefer.

I made the joke for Tom. It has special significance for him.

Re: Toml: Tom's Obvious, Minimal Language

#98
post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

damn it.. of course you would update the spec right before I release my config parser. =)

I have been working on a TOML reader/writer for golang that supports read/change/write and format (like go fmt) that sometime I will get enough time to actually finish and release. =)

Re: Toml: Tom's Obvious, Minimal Language

#99
Since Tom is browsing, I have a question - and this is my one and only major issue with TOML.

     # THIS IS INVALID
     a.b = 1
     a.b.c = 2
Why? I'm sure there is very good reasoning - but it makes me have to reason about my data in a manner I consider backwards/confusing.

     name.first = "Bob"
     name.last = "Smith"
     # Can't do this because name.first has already been defined 
     # name.first.alternative = "Robert"
     # This is too ambiguous 
     name.alternative = "Robert"
     # And this is backwards to me
     name.alternative.first = "Robert"
Some people might suggest to instead do

     first.name = "Bob"
     last.name = "Smith"
     alternative.first.name = "Robert"
But now nothing is scoped to [name] and if I need to get the full name I can't just pull in [name] but need to pull in [first], [last], and [alternative]. That's really messy in my opinion. All of these are names and should be scoped to [name] and not their own structure.

Re: Toml: Tom's Obvious, Minimal Language

#100

I just started a rust project and so had to learn TOML since that's what the package manager (and a lot of the ecosystem) uses. For some reason, though, I just struggle with the syntax. It says it's "obvious" but it wasn't to me. I think it says something that the README is full of "this TOML would be represented like this JSON", to help you understand what's going on. Every time I saw that, I was like "oh, now I get…

> Are there obvious downsides to JSON for config that I'm missing?

for me, there are two. firstly, TOML supports comments.

secondly, TOML or INI is very readable without indentation. i have learned that removing indentation from configuration files makes non-technical people much more comfortable editing the file by hand. when many non-technical people see braces and indentation, they feel overwhelmed and associate it with complexity.

i don't really use TOML's more advanced features, though. i basically just use it like INI.

Post reply on HN