Live data from Hacker News

Toml: Tom's Obvious, Minimal Language

github.com

111–120 of 204 posts

Re: Toml: Tom's Obvious, Minimal Language

#111
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!

You're welcome, really glad you like it, and good to know the double square brackets make sense to you! It does seem to be a bit polarizing, so we'll keep working on something even better.

Re: Toml: Tom's Obvious, Minimal Language

#113
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. =)

Hah, sorry! You can always release an 0.4 compatible first, and then add the stuff from 0.5. Sounds like a great project!

Re: Toml: Tom's Obvious, Minimal Language

#114
post #84

Earlier quoted context omitted.

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.

Dave and I worked together at Powerset many years ago (pre-GitHub) and wrote a bunch of Erlang together. We have a lot of inside jokes from those days. LEAVE HIM ALOOOOOOOOOOOONE!

Re: Toml: Tom's Obvious, Minimal Language

#115
post #52

Earlier quoted context omitted.

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

Quick link to a complex one:

https://github.com/habitat-sh/habitat/blob/master/components...

Re: Toml: Tom's Obvious, Minimal Language

#118
post #86
post #46

Earlier quoted context omitted.

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!

> There is no fuzzy interpretation of things like YES and NO I think the big problem is that YAML is dynamically typed. If I had schema-enforced config files, I'd be perfectly happy to say that for boolean typed data all the values of YES and NO and ON and OFF and T and F and 0 and 1 can all be reasonably interpreted as a Boolean True and False. The problem happens when a string-typed or integer-typed member can also…

Yeah, I'll agree with that, among many other issues with YAML. =) A schema would at least solve that problem, but I don't think most simple config users want to define a schema, so strong typing is a better solution.

Re: Toml: Tom's Obvious, Minimal Language

#119
post #76
post #20

Earlier quoted context omitted.

Yeah, it's not my favorite part either. We've made them mostly unnecessary by adding inline tables, but for heavy nesting of arrays of tables, you still need to use them, which is why I mentioned that there are still some weaknesses for large, complex config files. Hoping to make this better in 2.0.

In defense of double brackets, I first encountered TOML in pipenv[1], and just by experimenting found I could add another source. So they're reasonably obvious if you see them in an existing file. [1]: https://github.com/pypa/pipfile#pipfile

Yeah, they're ok for very simple use cases, it's when you start having more than one level of nesting that things get a little crazy.

Re: Toml: Tom's Obvious, Minimal Language

#120
post #107

Earlier quoted context omitted.

Tom, have you heard of EDN and Transit? Like JSON, but: 1. Extensible, custom types 2. Streamy, efficient, compressed and fast, leverages platform's existing native/optimized JSON parsers 3. Wide platform reach 4. Made by Rich Hickey http://blog.cognitect.com/blog/2014/7/22/transit

There is also a similar project - Hjson, a user interface for JSON- https://hjson.org/

For me, hjson takes on some of the warts of yaml (bare strings) which is why I prefer json5 if I'm going for a json variant.
Post reply on HN