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

Toml: Tom's Obvious, Minimal Language

github.com

Post reply on HN
Print view View original

51–60 of 204 posts

Re: Toml: Tom's Obvious, Minimal Language

#51

Post by jhabdas »

mojombo wrote: 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…

The one problem I've had, and perhaps I'm just doing something incorrectly, is going from a `[[something]]` back to a `[thing]` without TOML thinking that `thing` is part of `something` it's not.

Re: Toml: Tom's Obvious, Minimal Language

#52

Post by mojombo »

echohack5 wrote: post #50
mojombo wrote: 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…

Amazing, thanks for the heads up! I'll add it to the list of projects using TOML [1] and take a look at your example configs to get some more real-world uses cases to look at when evaluating future changes to the spec.

[1] https://github.com/toml-lang/toml/wiki

Re: Toml: Tom's Obvious, Minimal Language

#53

Post by laumars »

cies wrote: post #6
gnuvince wrote: post #3

Earlier quoted context omitted.

To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl

Yups. And making a whole datetime RFC part of the spec kind of broke with the "minimal" thing. But apart from that I totally prefer it over INF/YML/JSON/XML for many purposes.

Datetime does need to be part of the spec if you want your markup files portable otherwise every TOML parser might decode a date slightly differently. In that regard it is really no different to saying "01" (string) is different to 1 (integer) in terms of preserving your data's integrity.

Re: Toml: Tom's Obvious, Minimal Language

#54

Post by hyperpape »

mojombo wrote: 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…

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.

Re: Toml: Tom's Obvious, Minimal Language

#55

Post by mojombo »

hyperpape wrote: post #54
mojombo wrote: 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…

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) or maybe there's an array of strings that contains the names of the tables, each of which becomes an array member in that order. But these are hacks, and it would be nice to have a first-class way of dealing with nested large tables that was easy to scan and not too repetitive.

That said, the alternative right now in other formats is basically a { bunch { of { braces } } which is also not the most amazing thing for long nested tables.

Re: Toml: Tom's Obvious, Minimal Language

#56

Post by mojombo »

jhabdas wrote: post #51
mojombo wrote: 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…

The one problem I've had, and perhaps I'm just doing something incorrectly, is going from a `[[something]]` back to a `[thing]` without TOML thinking that `thing` is part of `something` it's not.

Curious. In order to be part of one of the tables in the [[something]] array, a table would need to be named [something.X]. What parser are you using? it's possible that it's behaving improperly in this case.

See the relevant part of the spec here: https://github.com/toml-lang/toml#user-content-array-of-tabl...

Re: Toml: Tom's Obvious, Minimal Language

#57

Post by clhodapp »

fastball wrote: post #11
somedudeatwork wrote: post #2

I never really questioned the name, TOML, but I guess "Tom's Obvious, Minimal Language" works

I'm more a fan of YAML. "YAML Ain't Markup Language"

TOML and YAML both have kinda weird names because both were initially incorrectly said to be a "markup language" and then subsequently renamed. The original names were "Yet Another Markup Language" and "Tom's Own Markup Language".

Re: Toml: Tom's Obvious, Minimal Language

#58

Post by k__ »

mojombo wrote: post #46
otterpro wrote: post #42

I didn't know about TOML until I started using Hugo. I've been using YAML and TOML and I find both have their merits, especially for their simplicity. TOML looks like the classic INI file, and is fairly easy to use/learn. I've been trying to move toward TOML for everything. YAML is nice, but I had to be careful about white-space significance and also translation of "YES","NO", etc. https://arp242.net/weblog/yaml_prob…

Absolutely. That's what I mean about TOML mapping unambiguously to a hash table. Strings in TOML are always quoted. There is no fuzzy interpretation of things like YES and NO. That way madness lies. I also am not a fan of meaningful whitespace, which is why TOML doesn't do that. Glad you're finding TOML useful, good luck on your projects!

I have to admit, the string and array syntax are the only parts that keep me from using it instead of YAML.

Probably because they are the only two features that need delimiters at start and end. The rest are only one-liners or simply stop if the next of the same type starts.

Re: Toml: Tom's Obvious, Minimal Language

#59

Post by hyperpape »

mojombo wrote: post #55
hyperpape wrote: post #54

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…

Thanks, is there a strawman proposal out there for fixing this, or is it something for the distant future?

Re: Toml: Tom's Obvious, Minimal Language

#60

Post by skrebbel »

jxub wrote: post #34
skrebbel wrote: post #22

If only package.json had been package.toml

Would that be hard to implement for npm/yarn? I'm sure that transforming TOML to JSON on the fly could be added as a step somewhere, resulting in changes to the package manager or just a wrapper command. Stylistically, I agree with you as TOML is clean and well thought. Moreover, TOML has support for more data types that JSON lacks leading to ugly workarounds (floats as strings anyone?). The main advantage of JSON is…

It would not be trivial because npm/yarn don't just read package.json but also modify it. See numerous GitHub issues in either repo about supporting comments inside package.json.

Of course nothing is impossible, but I think that the ship has sailed. I was just dreaming of what could have been :-) Subtle details in NPM's behavior would've probably been designed differently if it was necessary to make updates to the package file without destroying layout and context.

Post reply on HN