Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YAML: Probably not so great after all

arp242.net

Post reply on HN
Print view View original

221–230 of 457 posts

Re: YAML: Probably not so great after all

#221

Post by cuillevel3 »

Legogris wrote: post #207

Despite spending time writing and reading YAML on a daily basis for years, it still trips me up once things get non-trivial. It's definitely my least-favorite non-propritery config file format. XML might be overly verbose, but there are no surprises (unless you go bananas with schemas).

XML is great for documents too:

  Some text is here
And I found some things weird, like entities and (external?) DTD references.

But it's great for building your own formats. For data interchange it has it's problems, like no types. Everything is kind of a string. With encoding problems and XML in XML everything ends up in CDATA...

I think that's why XML makes for heavy parsers. I remember it was better in Java, because of the strong libraries.

Re: YAML: Probably not so great after all

#222

Post by dragonwriter »

rco8786 wrote: post #159
gjstein wrote: post #156

Earlier quoted context omitted.

This may be application-specific, but I might worry about security if my configuration files support arbitrary closures.

Any more so than the rest of your code?

Config files are typically written updated by non-developers and often go through a less rigorous release process, so having a less-complex and dangerous, even if less-capable, language can be desirable.

Re: YAML: Probably not so great after all

#223

Post by PopeDotNinja »

ivan4th wrote: post #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?

> the true horror starts when people start using text template engines to generate YAML

I just had a shiver recalling a Kubernetes wrapper wrapper wapper wrapper at a former job. I think there were at least two layers of mystical YAML generation hell. I couldn't stop it, and it tanked much joy in my work. It was a factor in me moving on.

Re: YAML: Probably not so great after all

#224

Post by zamadatix »

throwaway_391 wrote: post #186
thayne wrote: post #132

Earlier quoted context omitted.

> I never understood how YAML is more human-readable than JSON Two things: comments and multi-line strings.

My personal JSON Pet hate is: ``` x = [ "Foo", "Foo2", ] ``` Is not valid, but the following is: ``` x = [ "Foo", "Foo2" ] ``` Makes dealing with packer configs feel like punching yourself in the face. I still prefer it over YAMLs awkward initial learning curve.

At first I found it really annoying but then the more I thought about it the more I came to value the "," semantics as proper validation for a "forgot to put the last element in the list" error which would otherwise be silently hidden via the parser.

Re: YAML: Probably not so great after all

#225

Post by TJSomething »

twic wrote: post #188
mcphage wrote: post #73

Earlier quoted context omitted.

In the scale world, HOCON is very nice. It’s a format designed explicitly for config files, and has a lot of niceties (like you can append files together and they merge correctly, so you don’t have to end up with giant config files)

What's the "scale" world?

I think they meant "Scala", the programming language.

Re: YAML: Probably not so great after all

#226

Post by majewsky »

jackfraser wrote: post #158
majewsky wrote: post #37

Earlier quoted context omitted.

Verbosity certainly is an issue with XML, but far from the only one. IMO the main problem of XML is that it was designed as a markup language, but then misused as a data structure serialization language. When used as a markup language, the distinction between attributes and children is meaningful. When serializing data structures, the dichotomy breaks down. For most subfields of a larger data structure, it's not obvi…

> not obvious whether to serialize that subfield as an attribute or as a child. Attributes are just strings, generally for metadata. I'd probably serialize an object from another language more verbosely. This is where an important distinction needs to be made: the XML format you use for config files or for data exchange from your app to others should not necessarily be just a serialized object from the most convenien…

It's also the sort of problem that just doesn't exist at all if you use a real data serialization format from the get-go.

I'm so frustrated with our collective attitude of building abstractions upon abstractions upon abstractions, without ever stepping back and realizing that we're using the wrong tool to begin with.

Re: YAML: Probably not so great after all

#227

Post by devnulloverflow »

As much as I am an old-school Unix zealot, I think it is time to move towards a well standardised binary config format with non-trivial types (i.e a schema). There still has to be a standard text format, but only for the source from which the live configs have to be built. Done right, this has several advantages:

1. Built-time validation (or at least type checking).

2. Built configs can be easy to parse but (potentially) rich enough to avoid confusing templating.

3. Separation of concerns between storing/maintaining configs and applying them. E.g. scoop text configs off a source repo, but send out binary configs over the network.

All this is a fantasy in my head. Right now the closest mainstream thing is protobufs. But they make trade-offs for non-config use cases, and thus don't really cut it in the "... rich enough to avoid confusing templating" department.

Re: YAML: Probably not so great after all

#228

Post by ben509 »

booleandilemma wrote: post #166
fabian2k wrote: post #14

I've used YAML as the format for a config file, and I certainly regret that choice. Trying to explain to someone that doesn't know YAML how to edit it without setting them up for failure is quite annoying. There are too many non-obvious ways to screw up, like forgetting the space after the colon or of course bad indentation.

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

The main headaches are due to people either wanting to copy and paste code from various sites, or wanting to write really deeply nested code.

If you're writing well structured, original code in Python, it's generally cleaner and easier than other languages because the syntax avoids ambiguities that other languages have.

Re: YAML: Probably not so great after all

#229

Post by sigzero »

markmark wrote: post #160
crazygringo wrote: post #23

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.

JSON is for data. Not documents. Not config files. I don't agree with any "add this to JSON" comments. It's fine just as it is....for data.

Re: YAML: Probably not so great after all

#230

Post by dev_dull »

dharmab wrote: post #209
regecks wrote: post #206

Earlier quoted context omitted.

Why would they have chosen to use template/text to generate YAML? That seems insane. Surely using an encoder on an object/structure hierarchy (like people do with encoding/json) is the way to go? On the other hand, the quality of the yaml libraries in Go wasn't great, last time I had to choose a configuration file format.

A lot of people working with YAML have an ops background and aren't familiar with basic data structures.

personally I’d prefer a templatized yaml file over an over-engineered, snowflake DSL created by a “real programmer” and not an ops person.
Post reply on HN