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

71–80 of 204 posts

Re: Toml: Tom's Obvious, Minimal Language

#71

Post by bqe »

nixpulvis wrote: post #44
mojombo wrote: post #29

Earlier quoted context omitted.

1. How would the file path type differ from a regular string? Would you want specific semantic validation for each platform? 2. This is still a big question, and we've been having a robust argument about it on GitHub [1]. It's a problem that so far has evaded an elegant solution, but usually when that's the case, it just means we haven't been creative enough about it yet! Or did you mean versioning of the data IN the…

1. Yea the goal would be some kind of validation at parsing time. I'm not super familiar with TOML parsing, but there must be error cases in the implementations, so it seems like using `\` on UNIX systems, for example could return an error. The only hard part about this I see is distinguishing paths from strings syntactically without making TOML overly complex. 2. So basically, the majority of people don't want to ty…

Backslashes are valid characters in a POSIX filesystem, but they don't indicate a directory.

Re: Toml: Tom's Obvious, Minimal Language

#72

Post by mojombo »

ksec wrote: post #69
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…

> There are still some weaknesses in TOML that make it non-optimal for large, complex config May be the config shouldn't be large and complex in the first place? My biggest question is, why hasn't TOML used much more widely or becoming de facto standard? Am I missing something obvious?

I'm always in favor of small config files, but sometimes for larger projects that's just not possible (or desirable). TOML has always been about being as simple as possible while still solving a wide range of problems. But I think of it as the 80% solution, where 20% of projects might need something more powerful to solve their more complex needs, and that's ok. We still need a super simple config file format for the 80%.

As for adoption, it takes a long time for something like TOML to be adopted. Inertia is powerful in the development space. I also haven't had as much time as I would like to push TOML forward and evangelize it. My hope is that at some point there will be a tipping point and you'll see most projects start with a TOML config and only change to something else when TOML can't meet the project's needs.

Re: Toml: Tom's Obvious, Minimal Language

#73

Post by mojombo »

timvisee wrote: post #68

Cool. TOML is used quite extensively in Rust projects. I think it's awesome for very simple configurations. And newcomers don't have to learn anything in order to change a TOML configuration, which is very powerfull.

Yeah, Cargo and Rust have been really important in TOML gaining adoption. Love the Rust community!

Re: Toml: Tom's Obvious, Minimal Language

#74

Post by dustingetz »

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…

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

Re: Toml: Tom's Obvious, Minimal Language

#75

Post by mojombo »

epage wrote: post #67
mojombo wrote: post #43

Earlier quoted context omitted.

Homogenous arrays are partly to make implementations easier, and because if you really need that flexibility, you can always use an array of inline tables, which has the benefit of giving each sub-element a name, hopefully increasing the obviousness. I'm not sure I understand your complaint, though, can you give me another example of how it's biting you in real life?

> you can always use an array of inline tables, which has the benefit of giving each sub-element a name, hopefully increasing the obviousness Except the name would be duplicated with the content I'm storing. As for an example, its effectively Cargo. My use case is very similar (dependency reporting) but my content is slightly different (as I said, the value would effectively duplicate the key)

Oh, you mean you want something like:

  list = [
    "1.0",
    "2.7",
    { version = "1.4", path = "..." },
    "9.9",
  ]
Is that correct?

Re: Toml: Tom's Obvious, Minimal Language

#76

Post by ben509 »

mojombo wrote: post #20
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

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

Re: Toml: Tom's Obvious, Minimal Language

#77

Post by agumonkey »

mlthoughts2018 wrote: post #66
gnuvince wrote: post #24

Earlier quoted context omitted.

An array of dictionaries. In JSON, my example becomes: { "designers": [ {"name": "Guido", "lang": "Python"}, {"name": "Larry", "lang": "Perl"} ] }

This JSON is vastly more readable, frankly. It’s so clear what container type “designers” refers to, and I can read directly what data structures the elements are. I can’t do that in Toml. Unless I just happen to remember some rote memorized convention for what the syntax unpacks into, there’s no way to tell by looking at Toml code. IMO this ought to be priority number one for any utility language like this. No matte…

Nesting has locality value, which is often desireable.. but as I said, the [[toml]] syntax yields open arrays, it seems you can define thing in multiple passes (which can be harmful but may also be a need once in a while)

Re: Toml: Tom's Obvious, Minimal Language

#79

Post by mojombo »

dustingetz wrote: post #74
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…

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

I have not, and while it looks cool, it seems to be optimized for data transfer between applications, not a human readable config format.

Re: Toml: Tom's Obvious, Minimal Language

#80

Post by losvedir »

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 it." I don't know if that means JSON is just inherently more understandable, or I'm just more used to it, though.

Are there obvious downsides to JSON for config that I'm missing? What are the advantages of TOML over JSON? Maybe eventually it'll "click", though.

I think the following mean the same thing:

     [[foo]]
     bar = {baz = 5}

     [[foo.bar]]
     baz = 5
But I don't think the following works:

     [[foo]]
     [[bar]]
     baz = 5
That is, I think the double bracket syntax always starts at the top level? While the `=` are relative to the double brackets above it? Something about all that is non-obvious to me, and I don't love that there's multiple ways to do the same thing.
Post reply on HN