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.)<p>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 <i>advantages</i> 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.<p>This is a particularly rich irony in light of the fact that Erlang's native data model is <i>conceptually</i> 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.
The first requirement that I look for in a data interchange format is that it should be readable, because I don't want to look at binary data responses. The second thing I look at is support for encoding and decoding it.<p>The only three formats I've found so far that are readable and well supported are XML, JSON, and YAML. XML is too hefty and wasteful. YAML has had a bad history of insecure encoders and decoders but overall is my favorite data format. However, it still has the downside of needing a special decoder since browsers don't support it, and it requires specific indentation for its hierarchical data format which is wasteful in its own way.<p>That just leaves JSON in my opinion. It's easily understood and read, and native browser and Node.js encoding and decoding is more than fast enough.
This essentially amounts to "JSON is slower and more CPU intensive than it absolutely needs to be."<p>I can live with that. Any solution that people come up with, there will be folks who can point out some sort of flaw in it. Sometimes the flaws are worth paying some attention to, when fixing them might lead to some tangible benefits. It's difficult to imagine a slightly less CPU intensive replacement for JSON bringing any tangible benefits with it, though.
Only an Erlang mailing list would prompt someone to complain that a document format requires valid UTF-8.<p>This is a glimpse of the last place on earth where relying on US ASCII is considered a positive good.
Prefixed length formats that don't make assumptions on encoding are a very good pick. The most important thing is that once you read the length, you can just bulk-read the payload without actually parsing it, that's up to the higher layer (if parsing is needed at all).<p>A general purpose serialization format that requires per-char processing is a terrible pick.
> Its numbers representation is double-precision floating-point, meaning it's incredibly imprecise and limited.<p>Except that JSON actually just specifies the number type as an arbitrary precision decimal number.<p>Many implementations use floating point numbers when decoding JSON, but that is not inherent in JSON.<p>My biggest complaint about numbers in json is that often times floating point numbers get turned into integers when encoding/decoding using some implementations. (e.g. (float)2 gets encoded as just 2 and when decoding, it is an integer rather than a floating point.
JSON and Erlang just don't get along in the way you'd like them to, unfortunately. Some of that has to do with how Erlang handles (or doesn't handle) strings. Some of that was that there was not a data structure that closely mirrored JSON's structure in Erlang up until Maps were introduced.<p>The problem isn't really JSON - JSON is an exceptional format for what it is supposed to do - the problem is that Erlang was created for a specific purpose and that purpose wasn't to vend out strings/JSON over HTTP.
Since the author seems to have a problem with text-based formats in general, here's a counterpoint by Mike Pall on the LuaJIT mailing list [1]:<p>"On a tangent: IMHO most binary serialization formats like BSON, MessagePack or Protocol Buffers are misdesigns. They add lots of complications to save a couple of bytes. But that does not translate into a substantial improvement of the parsing speed compared to a heavily tuned parser for a much simpler text-based format."<p>[1] <a href="http://www.freelists.org/post/luajit/Adding-assembler-code-to-Lua-programs,12" rel="nofollow">http://www.freelists.org/post/luajit/Adding-assembler-code-t...</a>
So don't use JSON when you need super high performance and be careful about parsing JSON numbers?<p>It may not be perfect, but compared to the complexity of the XML world and the opaqueness of binary formats JSON is a very pleasant compromise.<p>Shame about it not having comments though.... :-)
The author suggests using MessagePack, which I hadn't seen before but looks really cool.<p><a href="http://msgpack.org/" rel="nofollow">http://msgpack.org/</a>
<p><pre><code> > * It has to be valid UTF-8, meaning it's incredibly
> slow to validate.
</code></pre>
If make basic mistakes about what the format allows, the rest of your comment is liable to be junk.
> It's text-based, meaning it's incredibly slow to parse.<p>This is precisely the reason it is used so heavily. Easily readable format to reason about. And <i>incredibly slow</i> is a pretty relative term, when you're waiting on database calls or doing other complex logic that is orders of magnitude slower, who cares how "slow" json parsing is.<p>> It has to be valid UTF-8, meaning it's incredibly slow to validate.<p>I think being able to embed all sorts of different characters and languages is, again a plus. See argument above about performance.<p>> Its numbers representation is double-precision floating-point, meaning it's incredibly imprecise and limited.<p>This argument I don't get. I'm pretty sure I might be missing something, but in my experience you can just put a plain old integer and any parser in any language will extract as an exact integer. Nobody is converting a "1" in json into a double/float. Maybe somebody can elaborate and what the author might have actually meant?<p>So, really, the argument all boils down to, it's slow and wasteful. Well, while that's true I think it's pretty much been established time and time again that Moore's law has made it possible to value programmer time over CPU overhead, to a reasonable extent (i.e. if the overhead you're adding overtakes Moore's law and makes infrastructure particularly expensive). If you have a format that is human readable, easy to understand, and simple, that helps tremendously in software development and it would take order of magnitude performance hits to really make it bad tradeoff (and even the, if you weren't getting a lot of traffic, who would care?), not just 2x or 3x.<p>We live in a web based world, and that world is fundamentally based on a text based protocol (http) and text based messaging formats. There are plenty of valid and good reasons why it happened the way it did.<p>*Final Note: I would like to see some empirical evidence to compare the wasted CPU cycles and energy that JSON uses compared to if all messages were sent with msgpack or something like it instead. While my own inclination is that number would be dwarfed by the overall energy used in computation I would prefer to see evidence rather then conjecture if you're going to make a point like that.
If msgpack is able to match JSON for serialization/deserialization, couldn't you make an API in JSON and offer msgpack as an alternative format?
Here the reasons why i use JSON:<p>* It's text-based, meaning it's readable and easy to parse.<p>* It has to be valid UTF-8, no hassle with other formats.<p>* Its numbers representation is double-precision floating-point, i can choose what i want.<p>Who cares? Use what you want and what solves your problem at the best way.