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

281–290 of 457 posts

Re: YAML: Probably not so great after all

#281

Post by isatty »

auslander wrote: post #276
dastx wrote: post #248

Earlier quoted context omitted.

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

Hell no, terraform is way better even though HCL isn’t the nicest DSL.

Re: YAML: Probably not so great after all

#282

Post by auslander »

isatty wrote: post #281
auslander wrote: post #276

Earlier quoted context omitted.

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

Hell no, terraform is way better even though HCL isn’t the nicest DSL.

3x times LOC, 1/3x speed and weird State corruptions? Not to mention dependence on 3rd party.

Re: YAML: Probably not so great after all

#283

Post by raymondh »

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.

I agree this a pretty choice.

Re: YAML: Probably not so great after all

#284

Post by mcphage »

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?

Sorry, yes, Scala. Autocorrect changed it and I didn't notice.

Re: YAML: Probably not so great after all

#285

Post by bhawks »

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…

I love proto, but the textformat was an after thought. The binary format is rigorously defined, portable, extensible and optimized. The text format was reverse engineered from the c++ implementation after the fact when folks found textproto useful. Unfortunately there are discrepancies between languages around the corner cases of the textformat and that's the sad world we live in. Avoid letting textproto be part of your user exposed interface.

Re: YAML: Probably not so great after all

#286

Post by brokensegue »

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's lack of int types is what ruins it for me

Re: YAML: Probably not so great after all

#287

Post by keithnz »

orf wrote: post #134
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…

Obligatory "thanks for fish shell". Try just using line-delimited JSON objects ( http://jsonlines.org/ ). It ticks all of your boxes, especially 3: "jq -s '.cmd' fish_history | histogram". Neither YAML or Protobufs are quite as easy as that. All in all it's ridiculously simple, easy to parse in a variety of languages and each row is a single line that's simple to iteratively parse without loading the whole thing into…

this seems like it makes json useful for logging, but not too useful as configuration. For instance, it doesn't support commenting, and it seems like every line needs to have all its children compressed onto one line?

Re: YAML: Probably not so great after all

#288

Post by JoBrad »

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.

And the required double quotes around strings. YAML’s string handling is a lot easier to deal with.

Re: YAML: Probably not so great after all

#289

Post by Ooolin »

twic wrote: post #195
dbcurtis wrote: post #88

Earlier quoted context omitted.

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.

Replace with "Element" with "Class" and "Attribute" with "Property" in your examples.

It's your job to decide how the data should be structured, in any language.

I would do the following :

Re: YAML: Probably not so great after all

#290

Post by c3534l »

cuillevel3 wrote: post #210

YAML is really so much more than JSON. * YAML can have several 'documents' in the same file,separated by --- * there are anchors and references * easy to read multi line texts * it's also a superset of JSON I can see, how choosing YAML when you just wanted readable JSON might give you more headaches than expected. And like someone else said, putting another template engine (or two) on top of YAML is when the real pro…

It's really to maintain JSON without being allowed comments. JSON is fine for transmitting data across the web, but if you need complex configuration data in version control that many people work on, you need comments so new teammates can be easily onboarded onto a project. There's definitely a need for something that is programming-language-like, but entirely about structuring and formatting data for configuration. YAML is the closest thing to that. It's not perfect, but it works better for that purpose than JSON or XML.
Post reply on HN