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

161–170 of 204 posts

Re: Toml: Tom's Obvious, Minimal Language

#161

Post by Rotten194 »

ErikAugust wrote: post #156
gregn610 wrote: post #92

Earlier quoted context omitted.

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!

{ “_comment”: “The comment goes here!”, “name”: “foo” }

So now your comments are flowing through infrastructure wasting bandwidth and possibly leaking internal configuration details?

Re: Toml: Tom's Obvious, Minimal Language

#162

Post by DCoder »

natefinch wrote: post #141
mlthoughts2018 wrote: post #138

Earlier quoted context omitted.

I disagree strongly. Config files being modified by anyone should be going through code review. The risk of not understanding while at the same time modifying things is extremely low. Plus, the documentation in the application code that loads the config and manipulates would function as the exact same reference documentation for any developer trying to understand how the config is used or why a choice is made. This p…

IF you have a 500k LOC software project... how the heck is an SRE/devops person going to figure out where in that code a specific configuration item is going to be used? They're not. This is why documentation is essential for projects. You could keep configuration documentation in a separate file... but that only helps for what the config does. It can't help you figure out why Bill (who left the company a while back)…

> It can't help you figure out why Bill (who left the company a while back) set ThreadMax to 650 when he changed the code 6 months ago. There cold be a commit message that references it, but that's more disconnected from the change that just slapping a comment on top that says why.

Also worth noting is that not all config files are committed to version control as-is. If a deployment process bakes the config file from variables, it can be even more disconnected and difficult to find the change.

Re: Toml: Tom's Obvious, Minimal Language

#163

Post by TheDong »

noisy_boy wrote: post #153

Some questions I couldn't find answers for: - Is interpolation supported? e.g. "key1" = "value" and then "key2" = "$key1". That would be very useful in avoiding repetition. - What is the keyword for null? e.g. when I want to set the value to null

> interpolation?

No, there is no facility for variable templating, interpolation, references, or anything of the like in toml.

If you wanted that, you could implement it in your application by doing post-processing on strings, or you could not use TOML.

> What is the keyword for null?

If you have "x = 1", you can always comment it out with "# x = 1". There's no specific support for null.

it would be kinda silly to have it anyways since null is a language construct more than anything else, and e.g. some lanuages support mixed strings + nulls in one array, but many don't.

Re: Toml: Tom's Obvious, Minimal Language

#165

Post by dnr »

mlthoughts2018 wrote: post #143
Waterluvian wrote: post #110

Earlier quoted context omitted.

I have never disagreed with someone more than I do now. =) Config absolutely needs comments. Context is everything. Comments allow me to explain to other humans why the config is the way it is. Dumping that out to a separate file is begging for it to fall out of sync when there's no comment instructing anyone to go and update the other file. Plus that's just kind of silly.

I disagree. It’s an anti-pattern. For example, if you’re writing an application that loads a default config file to populate parameters at run time, then the software module that loads from the default file is the correct place to document it, because the meaning of defaults is relevant to that source code, not at all to someone reading the parameter file itself. A parameter file is just some blob of stuff. I agree c…

You're talking about comments that document the semantics of fields in a config file. Most other people here are talking about comments that describe why the _specific values_ present in a _specific file_ were chosen.

Whether documenting semantics of fields belongs in a config file or code (I say both!), it simply doesn't make any sense to say that comments about why specific values in specific files are the way they are belong in the code that parses them. (How can the parsing code have knowledge of all config files out there?)

Re: Toml: Tom's Obvious, Minimal Language

#166

Post by simcop2387 »

mojombo wrote: post #72
ksec wrote: post #69

Earlier quoted context omitted.

> 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…

Yes I've got a project and config that I tried to stuff into TOML and even make my own DSL for it, but I haven't gotten anything satisfactory still. I've settled on some semiugly yaml for now until I try again

https://github.com/perlbot/App-EvalServerAdvanced/blob/maste...

The rest of the sandbox is configured with TOML however. Just seccomp rules that I haven't figured out the perfect way yet.

Re: Toml: Tom's Obvious, Minimal Language

#168

Post by simcop2387 »

tannhaeuser wrote: post #160
pcwalton wrote: post #91

Earlier quoted context omitted.

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 r…

This seems reasonable, but I'd like to add that XML, while certainly not designed as a config language, could be made much more terse by using SGML, the markup metalanguage XML is derived from and of which XML is a subset. SGML has additional constructs for short forms such as tag omission/inference and short references (custom Wiki syntax) targetted at authoring, whereas XML only admits canonical angle bracket marku…

While that's all true, in also not aware of any fine compliant sgml parsers in most major languages. That Maude's it have a rather high barrier

Re: Toml: Tom's Obvious, Minimal Language

#169

Post by simcop2387 »

mojombo wrote: post #16
aloisdg wrote: post #7

Earlier quoted context omitted.

v0.5.0 is a new release! Changelog: https://github.com/toml-lang/toml/blob/master/CHANGELOG.md#0...

Yes, we just released it two days ago! I know v1.0.0 has been a long time coming, but it's important to me that we get it right, as specs have a very long-lasting impact (much more so than a specific version of a library). We are indeed working hard towards a proper 1.0 though!

Something to consider for 1.0.0, a hexadecimal floating point type value. I don't think it's in there yet, but if it isn't https://www.effectiveperlprogramming.com/2015/06/perl-v5-22-...

They're incredibly useful if you need to specify an exact floating point value, and about rounding or precision issues.

Other languages than perl support them, but that article does a good job of demoing them

Re: Toml: Tom's Obvious, Minimal Language

#170

Post by mateuszf »

Rotten194 wrote: post #161
ErikAugust wrote: post #156

Earlier quoted context omitted.

{ “_comment”: “The comment goes here!”, “name”: “foo” }

So now your comments are flowing through infrastructure wasting bandwidth and possibly leaking internal configuration details?

And maybe even breaking code which doesn't what to do with these fields.
Post reply on HN