Hacker News Reader

Comment by rachelbythebay | Hacker News Reader

Have you seen what happens with YAML when you try to do something like

country: xx

... and get to Norway?

Congratulations, this is the first actual argument I've seen that has actually made me seriously consider never using YAML again.

The only thing this should tell you is that unquoted string literals are dangerous in yml.

And because they are dangerous in yaml, the format in itself is dangerous to use. That's why any sane person should seriously consider whether using the format makes sense.

I didn't like YAML from day 1, for this and many other reasons. I never understood why it caught fire like it did.

TOML seems to be catching steam. Would you say that’sa better alternative?

I've not encountered this format before, it looks really interesting, certainly much more human friendly than JSON. Thanks for sharing.

> TOML seems to be catching steam.

I am convinced that TOML is the _only_ reasonable configuration format, but very few seem to be swayed.

JSON and YAML are really not made for humans. Configuration must always be a hash. Configuration must allow for expository organization of the content to help humans understand what they are editing (comments, whitespace, section headings are very helpful). Parsing configuration should not result in unexpected code execution.

TOML satisfies those criteria.

I would love to see widespread adoption, but people still seem convinced that storing configuration in JSON is human friendly.

My personal favourites for humans are HCLv2 and its close cousin UCL (from FreeBSD).

HCL suffers from only having a reasonable implementation in Go, however.

YAML is clearly made for humans.

It's just that it's badly made for humans, in that it tries to be too helpful, leading to the various footguns scattered around the format.

TOML can be a bit verbose, especially if you have a case where your keys are more like sentences than they are like symbols. But there are no surprises, and it's quite pleasant to write by hand. I agree that it should be the first choice.

> YAML is clearly made for humans.

A format that allows references to other sections is not a configuration language that is usable by humans.

I understand the people who created it thought it would be usable by humans, but clearly it is too complicated for anyone to be able to understand a YAML file that is bigger than a dozen or so lines.

I still don't really like it, but I've since used it for adding I18n translations in rails and I can't think of a better alternative there.

It sounds like you might have a hard time selecting technologies to use of this kind of thing is a no-go for you.

Anything that accepts YAML will accept JSON.

I don't mean this in a "if you just swap the parser" way. I mean that in the "if you provide JSON to a program that expects YAML, it will parse it". JSON is a subset of YAML

So not only do you have a way of not using YAML, you can also force this decision onto most third-party services as well, and no-one will know the difference.

That's bananas. I feel like I've actually had to occasion to put this to use.

> JSON is a subset of YAML

That's false. http://p3rl.org/JSON::XS#JSON-and-YAML

There's a bunch of others to consider on noyaml.com

I only found out about this in the past few days, and now it keeps me up at night.

YAML sounded like a really great idea to me, until I started actually reading about it. It's a literal minefield.

Some parsers intentionally support subsets of the spec for this reason, and there's multiple specs (like 1.2 which dropped support for things like 'no' to mean false), but that also just means you need to be 100% certain your parser is set up correctly. It's just not worth the extra headache to me.

Yep. I like that you can map the text to programmatic types using the tag system, and anchors are wonderful if not a bit clumsy, but the rest of the standard leaving 10 ways to do 1 thing is just too messy for me.

You eliminate the risk and get to keep using it when you restrict yourself to never write YAML by hand. A YAML serialiser will not make the mistake.

This example might be a bit clearer as:

    country_code: NO

Huh. TIL, thanks! https://yaml.org/type/bool.html

I wonder how many Norwegians have encountered an instance of their country being rendered as "False".

I have yet to encounter this.

Norway is the opposite of Ontario, right?

In the context of YAML, the opposite is Yemen.

shakes fist at cloud

What’s the point in supporting so many ways of saying true and false?

Reply on news.ycombinator.com