Erlangers are particularly grumpy about JSON because unlike many other languages, Erlang lacks a decent default serialization and deserialization of JSON. This is primarily due to the fact that a string is a list of integers, thus making it hard to distinguish between the two, and somewhat less importantly, but still problematic, the klunkiness of the dictionaries. (This message appears to be in the context of the soon-to-come native addition of dictionaries, but as I imply, unfortunately that is not the biggest problem with JSON deserialization, the nature of strings in Erlang is. Binaries are not a precise conceptual match to a JSON string either, unfortunately; in my environment I actually use binaries that way because I can guarantee the differences won't affect me since I control both ends of the protocol, but that is not safe in general.)

This is not to say that the arguments are wrong, but I think you may not understand why Erlangers feel the way they do until you realize that Erlangers also don't generally get to experience the advantages of JSON, either; when you get none of the advantages and only the disadvantages, anything looks bad, no matter how good it may be in the abstract.

This is a particularly rich irony in light of the fact that Erlang's native data model is conceptually the closest language I know to natively using JSON as the only data type. Erlang has no user-defined types, and everything is an Erlang term... imagine if JS worked by only allowing JSON, so, no objects, no prototypes, etc. The entire language basically works by sending "ErlON" around as the messages, including between nodes. It's just that there's no good mapping whatsoever between Erlang's "ErlON" and JSON.