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

141–150 of 163 posts

Re: TOML – Tom's Obvious, Minimal Language

#141

Post by m463 »

hoseja wrote: post #91
shean_massey wrote: post #83

I had tons of headaches trying to get toml to do what's trivial in Json (nested arrays of objects of arrays of ... etc). 1/10 would not try again. For very simple, hear "flat" config it checks out. But then, so does yaml or even ini files. Anything requiring composite types was just a nightmare. I'd even prefer xlm before using toml again.

I never had to work with it seriously but I still don't get why people hate XML so much.

I think it allows too much and parsing it becomes a burden.

with json - you just suck it all into your data structure

with xml - sometimes people put stuff as a tag, sometimes as an attribute. Maybe not you, but someone else will do it.

Re: TOML – Tom's Obvious, Minimal Language

#142

Post by m463 »

admax88q wrote: post #2

I've always had a soft spot for the classic .INI style configuration. Modding command and conquer through "rules.ini" was always an adventure.

I used python configparser and there's a grey area when configs are merged (like default stuff and user-config'd stuff)

Re: TOML – Tom's Obvious, Minimal Language

#143

Post by BiteCode_dev »

bronson wrote: post #132
BiteCode_dev wrote: post #124

Earlier quoted context omitted.

That's not config data that you have here, that's your program input (hint: you pipe it to stdin). TOML is for config, config that users edit by hand, not input.

That looks like hand-edited config to me. At least, I've maintained files similar to that in past gigs. It's a nice example of how CSV can work well if you don't need to worry about quoting.

1 - you don't pipe config to stdin. If you use standard input, that's your main input.

2 - config sets your program boostrapping state. It's not the main data your program processes. That's your main input. IP addresses are what the script processes. It's not config.

Re: TOML – Tom's Obvious, Minimal Language

#144

Post by BiteCode_dev »

jiggawatts wrote: post #131
BiteCode_dev wrote: post #124

Earlier quoted context omitted.

That's not config data that you have here, that's your program input (hint: you pipe it to stdin). TOML is for config, config that users edit by hand, not input.

Config is data. Data is input.

Anything that is not hardcoded is technically input.

But there is a reason we have a word for config.

It's a specific kind of input: it feeds the boostrapping state of your program, it's not the main data your program process.

The difference is important: structure, complexity and dynamism requirements are not the same.

Re: TOML – Tom's Obvious, Minimal Language

#145

Post by curryst »

jiggawatts wrote: post #134
secondcoming wrote: post #110

Earlier quoted context omitted.

> If you roll your own, it'll be about 10x less efficient than something done properly using SIMD instructions. Is this really an issue when loading a field from a config file? If it was something happening 1m times per second then maybe I could see your point.

JSON is now at the point where yes, it does makes sense to optimise it with AVX2 instructions. https://github.com/simdjson/simdjson

JSON is in a slightly different area since it's commonly used as a serialization format for RPC/REST so it's in a hot path. Optimizations there make a lot of sense; optimizations on reading your configuration file are almost certainly premature optimizations.

The fact that your config will load some tiny amount faster with those optimizations is a side effect of the hot path optimizations, not a requirement for config formats.

Re: TOML – Tom's Obvious, Minimal Language

#146

Post by bronson »

BiteCode_dev wrote: post #143
bronson wrote: post #132

Earlier quoted context omitted.

That looks like hand-edited config to me. At least, I've maintained files similar to that in past gigs. It's a nice example of how CSV can work well if you don't need to worry about quoting.

1 - you don't pipe config to stdin. If you use standard input, that's your main input. 2 - config sets your program boostrapping state. It's not the main data your program processes. That's your main input. IP addresses are what the script processes. It's not config.

1 - If you google 'config stdin' you'll see a number of good reasons a program might want to accept configuration on stdin. (also, not that it matters, but my program read it from a file)

2 - Those IP addresses are probably not the main data the program processes. In my case, they were configuration, describing where an auditing processor scrapes input and how to allocate compute.

Re: TOML – Tom's Obvious, Minimal Language

#147

Post by CameronNemo »

renox wrote: post #92
CameronNemo wrote: post #73

Earlier quoted context omitted.

There are a few projects with a similar feel as json yet allowing nice to haves like comments and trailing commas: * json5 * HCl * hjson (now unmaintained)

> hjson (now unmaintained) Which is quite sad, as I thought that it was the best one (if memory serves)..

I tried the go and rust implementations and they each had subtly broken behavior for things like leading slashes in key names or trailing commas. I want something much more strict than "human" json. Maybe a "lizard person" object notation would fit me better.

Re: TOML – Tom's Obvious, Minimal Language

#148

Post by GoblinSlayer »

jiggawatts wrote: post #133
3np wrote: post #122

Earlier quoted context omitted.

It sounds like you should store your configuration in some sort of KVS (Consul or etcd) or database (SQL) with a frontend rather than flat text files. There exists tooling for all of that. If you're really going for Excel, why not even make a plugin that hooks in to it. Personally I'd find that horrible, but if it works for you and your team has no objections, why not. I'd wager that the major reason no one has taken…

There is an awful lot of middle ground between the scale where it's faster to just click through a GUI, and the scale where a database engine makes sense. Sure, if I were provisioning 10K+ more-or-less-but-not-entirely-the same objects, I'd be reaching for a SQL database engine of some sort. For about 10 things I'd just grit my teeth and click through a GUI manually. In between 10 items and 10K is where things get in…

There's https://www.gnu.org/software/recutils/ aimed for that scale.

Re: TOML – Tom's Obvious, Minimal Language

#149

Post by BiteCode_dev »

bronson wrote: post #146
BiteCode_dev wrote: post #143

Earlier quoted context omitted.

1 - you don't pipe config to stdin. If you use standard input, that's your main input. 2 - config sets your program boostrapping state. It's not the main data your program processes. That's your main input. IP addresses are what the script processes. It's not config.

1 - If you google 'config stdin' you'll see a number of good reasons a program might want to accept configuration on stdin. (also, not that it matters, but my program read it from a file) 2 - Those IP addresses are probably not the main data the program processes. In my case, they were configuration, describing where an auditing processor scrapes input and how to allocate compute.

Scraping is not bootstrapping. That's the main process. Main input can have several sources.

Re: TOML – Tom's Obvious, Minimal Language

#150

Post by g8oz »

jiggawatts wrote: post #4

TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…

I recently read that YAML has a way of specifying a "sequence of sequences" which could work for tabular data like that in your example. i.e

  - [Server,Subnet,IP]
  - [db01,databases,10.1.2.3]
  - [db02,databases,10.1.2.4]
  - [user01,filers,10.3.10.1]
  - [user02,filers,10.3.10.2]
That being said, the CSV does seem more straightforward.
Post reply on HN