Live data from Hacker News

YAML: Probably not so great after all

arp242.net

201–210 of 457 posts

Re: YAML: Probably not so great after all

#201
post #184

Earlier quoted context omitted.

Sort of, I deliver a GUI that exports into YAML for pretty much only reading, portability, and version control. People are expected to do the editing in the GUI, only using YAML for editing when doing complex regex operations that my GUI doesn't support.

If people aren't editing it by hand, why does the format matter? Why not just use JSON? Tools for too-complex-for-the-GUI manipulations are at least as good for JSON as they are for YAML, and the editing is less error-prone.

Internally it is JSON. It exports as YAML for readability when sharing on discord.

Re: YAML: Probably not so great after all

#202

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.

YAML is easier to read and write. That's the benefit. It's also always going to be smaller than anything JSON or XML. Maybe it's not as correct, maybe some people don't like it, I don't really mind it. I don't see it really going anywhere soon either considering Kubernetes and the lack of alternatives in widespread usage.

I've never had someone that needed extensive help understanding YAML and that's besides reviewing work for people just coming up to speed. Find me an IDE or editor that doesn't have YAML support. Also, YAML supports comments so if you have pitfalls people need to know about you can document them inline.

Your argument is people who don't know things might screw stuff up. Well Yeah! This applies to everything.

Re: YAML: Probably not so great after all

#203

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?

Kubernetes API accepts only JSON with a single exception of Server-Side Apply which is an alpha feature.

Re: YAML: Probably not so great after all

#204

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.

Yep. Some kind of JSON++ is where we're headed. Hopefully we can agree on a new standard someday?

(No, not YAML.)

Re: YAML: Probably not so great after all

#205

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?

Re: YAML: Probably not so great after all

#206

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.

Re: YAML: Probably not so great after all

#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).

Re: YAML: Probably not so great after all

#208

I strongly recommend doing away with config files completely for sake of ease of use, maintainability and security. Instead just declare all config variables within code itself in a separate config class/module file, along with initialization to default values and provides dynamic getter/setter interface over a debug API (which can be enabled/disabled via a command line flag). If you want, you can also provide a frie…

[deleted]

Re: YAML: Probably not so great after all

#209

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.

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

Re: YAML: Probably not so great after all

#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 problems start.

Post reply on HN