Live data from Hacker News

YAML: Probably not so great after all

arp242.net

191–200 of 457 posts

Re: YAML: Probably not so great after all

#191

I'll say it: I think YAML is great and a joy to use for configuration files. I can write it even with the dumbest editor, I can write comments, multi-line strings, I can get autocompletion and validation with JSON schema, I can share and reference other values. It allows tools to have config schemas that read like a natural domain specific language, but you already know the syntax. I haven't had problems with it at a…

This was me too - until yesterday, when I made a minor change to one of our YAML config files and everything broke. On investigation it turned out that all of our YAML files had longstanding errors but those errors happened to be valid syntax and also did not cause any bad side effects, so we had been getting away with it by pure luck until I made a change that happened to expose the problem.

So now no longer a YAML fan...

Re: YAML: Probably not so great after all

#192

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

Been working more with Dhall and have really enjoyed it so far. https://dhall-lang.org/

Putting commas at the start of the line is the toe shoes of syntax.

Re: YAML: Probably not so great after all

#193

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

My vote is yes. Most configuration doesn’t need anything more sophisticated than key-value pairs, perhaps with namespaces. INI can manage that and TOML is basically a better-specified INI.

I can't tell if I've spent too much time on HN or if I came to this conclusion on my own, but TOML is my language of choice for configuration now. It's flexible in the right ways and sectioning of config is so important.

Re: YAML: Probably not so great after all

#194

I'll say it: I think YAML is great and a joy to use for configuration files. I can write it even with the dumbest editor, I can write comments, multi-line strings, I can get autocompletion and validation with JSON schema, I can share and reference other values. It allows tools to have config schemas that read like a natural domain specific language, but you already know the syntax. I haven't had problems with it at a…

This was me too - until yesterday, when I made a minor change to one of our YAML config files and everything broke. On investigation it turned out that all of our YAML files had longstanding errors but those errors happened to be valid syntax and also did not cause any bad side effects, so we had been getting away with it by pure luck until I made a change that happened to expose the problem. So now no longer a YAML…

That would make me not a fan of the particular parsers/validators I've been using, rather than not a fan of YAML.

The big strike against YAML I see there is that it needs a good conformance test suite and implementations need to be tested against it. But that's not a problem with the format but a fairly easy to fix ecosystem problem.

Re: YAML: Probably not so great after all

#195
post #78

Earlier quoted context omitted.

Is there an agreement on whether it’s or pete yet?

Attributes are XML’s foot-gun.

Particularly annoying is that there's no way to do lists with attributes. Looks good:

  
Oh no:

  
Or is it one of:

  
  
  
Or give up and use elements:

  
    wheel
    admin
    sudoers
  
Hold on, should there be a container?

  
    
      wheel
      admin
      sudoers
    
  
XML really needs either richer attributes, or no attributes.

Re: YAML: Probably not so great after all

#196

Earlier quoted context omitted.

Giving meaning to whitespace causes so many headaches and yet people still embrace Python, for some reason. I don’t understand it.

Your editor makes a world of difference here. Since you shouldn't be writing brace-language code without indents anyways, the biggest issue remaining is mixing tabs and spaces. Gedit makes this a big pain with it's default config (it doesn't even auto-indent) but Atom and IDLE handle it well.

I’ve heard this argument in a lot of contexts, and it has always struck me as saying, “if hitting yourself with this bat hurts, try wrapping this towel around it and maybe it will hurt less.”

Re: YAML: Probably not so great after all

#197
From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?

Re: YAML: Probably not so great after all

#198

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

If possible, prefer what tools in your vicinity use. My team uses Kubernetes and Concourse extensively, which both use YAML, so I tend to stick with YAML since people are already familiar with it. (More recently, I've come around to prefer plain environment variables for configuration, but that only works nicely when the amount of configuration is fairly limited, say 20 values instead of 1000 values.) For my own use,…

Perfect comment! I agree 100%.

Re: YAML: Probably not so great after all

#199

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

I say just use JSON. Everyone knows it already and it's good enough. Use a parser in your app that allows comments and trailing commas like vscode does.

I dislike json with comments or trailing commas as even if your parser can handle them, it surprises many text editors.

Aside from lack of comments, the other major thing that can sometime make json a bad config choice is lack of multi-line strings.

Post reply on HN