Hacker News Reader

Comment by donatj | Hacker News Reader

Every YAML parser I've ever used has been literal magnitudes slower than the slowest JSON parser. It's way too flexible a format.

> YAML may seem ‘simple’ and ‘obvious’ at a glance, but it’s actually not. The YAML spec is 23,449 words; for comparison, TOML is 838 words, JSON is 1,969 words, and XML is 20,603 words.

https://arp242.net/weblog/yaml_probably_not_so_great_after_a...

View on HN

If data is so big that parsing is a bottleneck, that seems like the wrong case for YAML. It's good for hand-edited and human-readable config files, and it's fast enough for that.

Hand-edited and human-readable? With significant whitespace and tab-space difference?

Human readability is exactly the point of significant whitespace. And I'm not sure how significant whitespace could even work without distinguishing between tabs and spaces, as a tab could represent any number of spaces.

You cannot indent yaml with spaces instead of tabs. This has been a source of confusion for years for many bukkit end-users.

Toml is far superior for hand editing. This is why yaml is terrible (aside from significant white space):

    foo: 80:80
    bar: 22:22
    baz: 22.22

What's the value of foo? It's the string "80:80". What's the value of baz? The float 22.22 What's the value of bar? The integer 1342.

I rest my case about both readability and writability.

> bar: 22:22

I know zero toml (don't even know what toml stands for) but I'm pretty sure you meant the value of bar is the string 22:22 based on foo.

I think he's attempting to point out a shortcoming of yaml; I can reproduce it myself in Python.

That said, I've never run up against this myself - in the face of potential ambiguity I attempt to be explicit, and surround it in quotes to be explicit string.

TOML itself is going through its own growth pains brought on by a rather sizable spec. For example:

    >>> pytoml.loads("foo = 20:20:20")
    [...]
    pytoml.core.TomlError: <string>(1, 9): msg

I agree that's a downside, but it almost never comes up in practice, and it's solved by syntax highlighting when it does. I'm always in a code editor when editing YAML, it's not something that goes down the wire and needs to be debugged without syntax colours. For config files it's fine. Maybe TOML is even better, I haven't used it. I'm just saying these problems raised about YAML have never really affected me and I use it all the time. For config only. JSON for data exchange.

If it's something you do thousand of times a second, like say a php app parsing a config it makes a HUGE difference. A number of PHP framework that use YAML config files actually cache the results in memcache because a network request is faster than parsing YAML from local disk.

If it's something you do thousands of times a second, then opening, reading, and parsing a config file is absolutely something you should be caching, no matter the implementation.

It's got a lot of bad features which should not really be used. The core is good though.

The problem with talking about 'cores', is I still have to parse and handle the entire language if I want to claim to support YAML.

I've used JSON is some constrained places, I can't imagine writing my own YAML parser, or hacking an existing one into a constrained place (no memory allocation for example).

Reply on news.ycombinator.com