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

271–280 of 457 posts

Re: YAML: Probably not so great after all

#271

Post by zbentley »

zrail wrote: post #241
devnulloverflow wrote: post #227

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

SQLite databases might fit the bill. Fairly lightweight. Can talk to them in basically any language. Instead of templates you copy the database file and issue some UPDATEs.

They don't type check though; most constraints arent enforced, and the underlying reality (slinging around mostly strings) leaks out often.

Re: YAML: Probably not so great after all

#272

Post by Noumenon72 »

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

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.

What is "an encoder"? Like a function that takes the same variables as the template would but does some work itself generating things?

Re: YAML: Probably not so great after all

#273

Post by EamonnMR »

zzo38computer wrote: post #270
norcalli wrote: post #267

Earlier quoted context omitted.

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.

Having spent a nontrivial amount of my life hand editing large JSON files now, I have to agree here. Lack of comments and trailing commas are a real QOL issue.

Re: YAML: Probably not so great after all

#274

Post by nine_k »

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?

JSON is serviceable as an intermediate format, machine-generated and machine-consumed.

It is outright bad as a human-operated format. It explicitly lacks comments, it does not allow trailing commas, it lacks namespaces, to name a few pain points.

YAML is much more human-friendly, with all its problems.

Re: YAML: Probably not so great after all

#275

Post by nine_k »

theli0nheart wrote: post #205
ridiculous_fish wrote: post #96

fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…

TOML?

TOML is great when your data are mostly flat.

Re: YAML: Probably not so great after all

#276

Post by auslander »

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…

> This was actually great as it CloudFormation is extremely verbose and often unnecessarily complex

I think its opposite, the most lean way to deploy AWS resources. Did you wrote it yourself, in text editor? I was doing it for 5 years now. You can omit values if you're fine with defaults, you only state what needs to be different. Other tip is use Export and ImportValue to link stacks.

I kept on using JSON, even after all my buddies jumped on YAML. JSON is just more reliable, harder to miss syntax errors, and can be made readable by not using linters and keep long lines that belong on one line. Also, the brackets are exactly what they are in Python :)

> wraps CloudFormation with a templating language (jinja2)

Not sure it it is a good idea. Everyone's use case is different, though. A well written CFN template is like a rubber stamp, just change the Parameters. The template itself doesn't need to change.

Re: YAML: Probably not so great after all

#278

Post by reilly3000 »

reilly3000 wrote: post #176

Kubernetes supports JSON but overwhelmingly leans towards YAML. I've had to spend some time really grokking it to do basic dev ops, and now have my IDE pretty dialed to support it. That said, its not my favorite by a long shot. Can Jsonette save us?

I should clarify that kubectl converts YAML to JSON, so most examples I see are in YAML in a repo, then applied by a CI system via kubectl where it is transformed into JSON.

Re: YAML: Probably not so great after all

#280

Post by breck »

dfee wrote: post #213
breck wrote: post #178

Earlier quoted context omitted.

Disclaimer: I work on Tree Notation. ( https://github.com/treenotation/jtree ) Here's a proposal: use a Tree Language. I created a demo for you called "Fished": https://github.com/breck7/fished . Took me just a few minutes but already get type check, autocomplete, syntax highlighting, and more. Tree Notation is early, and there will be kinks until the community is bigger, but I think it may be useful for you. http://…

Wow. This looks really cool. Is there a sort of design defense on how this was designed (tree notation)?

Not sure if I’m familiar with the term “design defense”. Can you explain?

Stumbled into the idea. Basically just brute forced it. Tried thousands of things, built a huge database of languages, and tried to keep it simple.

Post reply on HN