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

261–270 of 457 posts

Re: YAML: Probably not so great after all

#261

Post by zwkrt »

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

At my old place we developed a small tool that wraps CloudFormation with a templating language (jinja2). This was actually great as it CloudFormation is extremely verbose and often unnecessarily complex. Templating it out and adding custom functions to jinja2 made the cfn templates much easier to understand. I think it all depends. Most of the time I would agree that you shouldn't template yaml, but sometimes, it's t…

Templating CFN is really good practice once you hit a certain scale. If you have 5 DDB tables deployed to multiple regions, and on each of them you want to specify keys, attributes, throughput, and usage alarms, at a minimum. That’s already 30-40 values that need to be specified, depending on table schemas. Add EC2, auto scaling, networking, load balancer, and SQS/SNS—now untemplated cloud formation is really unpleasant to work with.

Some of the values like DDB table attributes are common across all regions, other values like tags are common across all infra in the same region. Some values are a scalar multiple of others, or interpolated from multiple sources. For example, a DDB capacity alarm for a given region is a conjunction of the table name (defined at the application level), a scalar multiple of the table capacity (defined at the regional deployment level), and severity (owned by those that will be on-call).

To add insult to injury, a stack can only have 60 parameters, which you butt up against quickly if you try to naively parameterize your deployment.

Given all these gripes, auto-generating CFN templates was easiest for me. I used a hierarchical config (global > application > region > resource) so the deployment params could be easily manipulated, maintained, and where “exceptions to the rule” would be obvious instead of hidden in a bunch of CFN yaml. To generate CFN templates I used ERB instead of jinja, but to similar effect.

A side benefit of this is side-stepping additional vendor lock-in in the form of the weird and archaic CFN operators for math, string concatenation, etc. I don’t have a problem learning them, but it’s one of those things that one person learns, then everyone who comes after them has to re-learn. My shop already uses ruby, so templating in the same language is a no-brainer.

Re: YAML: Probably not so great after all

#262

Post by Izkata »

dragonwriter wrote: post #194
martinpw wrote: post #191

Earlier quoted context omitted.

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.

> of the particular parsers/validators

But the syntax was valid, the parsers/validators would've been correct to accept it.

Re: YAML: Probably not so great after all

#263

Post by edraferi »

j0057 wrote: post #146
akx wrote: post #100

Earlier quoted context omitted.

How about JSONL (JSON Lines)? http://jsonlines.org/ Ps. Thanks for (all the) fish, it's my daily driver shell and keeps me that much more sane c.f. the alternatives.

That's really close to [RFC 7464]( https://tools.ietf.org/html/rfc7464 ), JSON Text Sequences. It uses U+001E RECORD SEPARATOR. The `jq` tool supports those if you pass a flag.

So just add a record separator at the end of each line?

Re: YAML: Probably not so great after all

#266

Post by markmark »

dagenix wrote: post #182
markmark wrote: post #160

Earlier quoted context omitted.

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.

That's not JSON anymore, that's some custom format that's JSON inspired.

Cool. It doesn't matter.

Re: YAML: Probably not so great after all

#267

Post by norcalli »

jchw wrote: post #181

The issue is, I think most people (myself included) enter YAML into their lives as basically a JSON alternative with lighter syntax. Without really realizing, or perhaps without internalizing, the rather ridiculous number of different ways to represent the same thing, the painful subtle syntax differences that lead to entirely different representations, the sometimes difficult to believe number of features that the l…

I've never understood this. JSON is really not that difficult to work with manually. I tend to write my config files as JSON for utilities I write. What is it with peoples' innate aversion to braces?

Re: YAML: Probably not so great after all

#268

Post by DangitBobby »

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 difference in my experience is that once you know what's wrong with your whitespaces in Python, you're out of the woods. The interpreter is your friend from that point onward. YAML parsers, on the other hand, give you these really strange errors that are pretty difficult to understand, and it doesn't end with whitespaces.

Re: YAML: Probably not so great after all

#269

Post by zbentley »

crdoconnor wrote: post #251
zenexer wrote: post #239

Earlier quoted context omitted.

They’re fairly useful in applications that use numeric IDs. For example, if I’m using SQL, and I have a table with an AUTOINCREMENT primary key, I’m going to have a lot of numeric IDs. If I want to reference these in a config file of some kind, I don’t want to have to read them as strings and handle the parsing on my end. Even if you’re of the opinion that IDs shouldn’t be numeric, there are a lot of cases where you’…

Ah I see, yes that makes perfect sense. I've used integer keys too. Sorry, I thought by non-string you meant non-scalar - i.e. the idea of using lists as keys (allowed in YAML).

I think they did mean nonscalar keys. Say I have a compoubd primary key in a database, over 3 columns. In YAML, representing that key as an array of the three columns' values (or a map from column name to value) makes sense, and so does using that as a key in other maps.

Re: YAML: Probably not so great after all

#270

Post by zzo38computer »

norcalli wrote: post #267
jchw wrote: post #181

The issue is, I think most people (myself included) enter YAML into their lives as basically a JSON alternative with lighter syntax. Without really realizing, or perhaps without internalizing, the rather ridiculous number of different ways to represent the same thing, the painful subtle syntax differences that lead to entirely different representations, the sometimes difficult to believe number of features that the l…

I've never understood this. JSON is really not that difficult to work with manually. I tend to write my config files as JSON for utilities I write. What is it with peoples' innate aversion to braces?

I don't aversion to braces. Rather, my issues with JSON is that it doesn't have comments and that you cannot use a optional trailing comma.
Post reply on HN