Hacker News Reader

Comment by AdieuToLogic | Hacker News Reader

As I mentioned in a reply to a peer comment, the problems you describe regarding YAML appear to be about the commonly used format most of us think of and the totality of the YAML feature set.

What is illustrated above is the definition of a specification-compliant YAML resource strictly using JSON constructs + octothorpe end-of-line comments.

Does this usage mitigate the concerns you have identified?

View on HN

The problem is that self-restraint only takes you so far. Typos exist. Human mistakes exist. Machine errors exist. Malicious inputs exist.

A good parser does not just accept the inputs you find valid, but also rejects inputs you deem invalid. Running a linter that would report or amend all the footgun-wielding features of yaml before parsing is tanamount to running another parser. Then why bother :)

All good points. My philosophy to address same is to employ test suites as a form of sanity checking for JSON/YAML/XML/et al configuration resources.

Still, it would have been nice if YAML had reduced the surface area to verify in order to establish confidence in its content.

Using a YAML parser to parse JSON+comments is like bringing a tank to a knife fight... If you only parse "trusted" input, i.e. you can guarantee that no one is ever going to pass anything but JSON+comments, and you don't do it in any high-TPS scenarios it's probably fine to use a YAML parser

Reply on news.ycombinator.com