Hacker News Reader

> And let's not forget: JSON and XML have some significant advantages over most other serialization formats. They're ubiquitous. Practically every programming language has libraries to parse and generate them.

One of the interesting things about Erlang is it has binary pattern matching. Matching any binary in it is just as trivial or even more trivial than parsing json in other langauges.

Here is what an IP packet parsing might look like:

    <<4:4, HeaderLength:4, _DiffServ:8, _Length:16, _Identification:16,
      _Flags:3, _FragOffset:13, _TTL:8, Protocol:8, _HeaderChecksum:16,
      SrcAddr:32/bits, DstAddr:32/bits, OptionsAndData/bytes>>

It looks almost like casting a binary blob to a C struct, but you can do even crazier things like take Length and match it later in the pattern, if it specifies a length prefixed binary, for example.

> the difference in data usage would scarcely be measurable

It depends. See, Joe's background is from Ericsson. Their stuff controls access of 50% of world's smartphone <-> internet traffic. When people say "but who uses functional languages in the industry?" the answer is if functional languages won't work, chances are high, you won't see picture of cats on your smartphone.

But the idea is that mobile bandwith is still a precious resourse. Even if our CPU and hard drives are getting bigger. That is one shared resource that is expensive. Maybe if a 1M clients use JSON vs a binary protocol doesn't make a difference much for some startup, when we talk about billions of connected devices talking over radio waves, those things add up. Well, also, game servers use UDP and binary often because of latency. Facebook knows a thing or two about chatting with lots of users, so they use Flatbuffers https://code.facebook.com/posts/872547912839369/improving-fa... that's binary as well.

I think it's also important to note that json isn't exactly something that can be streamed while parsed.

There are multiple libraries doing just that. For example https://sites.google.com/site/gson/streaming

From personal experience, I can tell you that is can. The i3 window manager in Linux comes with a status bar program called i3bar. It also includes a program called i3status which constantly feeds i3bar information to display via JSON through a standard pipeline.

I wrote an i3status replacement that does exactly this. It sends JSON to STDOUT at a set time interval. i3bar takes the JSON as it comes through STDIN and changes the look of the bar as it's read.

While very informative and interesting, I don't think your comment really engages with my point. I never mentioned Erlang or functional programming. I'm just talking about data serialization. Namely, that sending JSON or XML over the air isn't "totally crazy".

Again, the vast majority of mobile data isn't JSON or XML. If mobile bandwidth was a Californian drought, video would be alfalfa farming. JSON would be taking a long shower: maybe you feel a little bad, but it doesn't matter. All the short showers in the world can't make up for the huge volume of water (bandwidth) used by alfalfa (video).

Obviously, if you have a billion users, trade-offs change and it can make sense to use esoteric or bespoke protocols. But even for Facebook, using JSON isn't crazy. It's just inefficient. And Facebook didn't switch to FlatBuffers for the bandwidth savings. Their primary goal was to improve loading times for their local cache. Had FlatBuffers required 10% more network traffic than JSON, they likely still would have made the switch.

> I don't think your comment really engages with my point. I never mentioned Erlang or functional programming [...]

Sorry. It was mainly a response to "JSON and XML are only 'wasteful' if you don't count developer time. Once you do, it suddenly makes a lot of sense to "waste" hardware resources. After all, programmers are expensive. Hardware is cheap."

And pointing out that it really depends on what languages or type or programmers you use and what "hardware" is. In some languages binary parsing is really easy and just as cheap and elegant as using a json parser. And well, Joe is Erlang's father, so point out Erlang was obvious choice.

As for hardware, bandwidth is not hardware. It really is "something else" -- a shared resource usually. And if there are enough devices using this even small changes start to make a difference.

Think a bit like a nested loop -- a small optimization in the inner loop might have large visible benefits. Or say, a huge database with 10B records, choosing an 32bit int vs an 16bit one for a column will make a for a good difference in size. That is basically where Joe was coming from. Really valuing bandiwidth as a shared resource. (He also likes to talk about protocols as well quite a bit).

> Again, the vast majority of mobile data isn't JSON or XML

The important data is JSON though, the control message, the pages that load (and they are slow), stuff that stops, start, manages everything all that is JSON.

> If mobile bandwidth was a Californian drought, video would be alfalfa farming

Hmm, video is 50% of all traffic on smart phones. (http://www.ericsson.com/res/docs/2015/ericsson-mobility-repo... says 45% in 2014). Not that the rest is all JSON but, I wouldn't say it is all just "taking showers" type of equivalency, it is more like grapes, almonds, strawberries, and walnuts.

Remember to also subtract images, audio, and other actual content and code from the remaining 50%. And realize that if you're using a flat structure to encode hierarchical data, you'll have to encode that hierarchy somehow. Then subtract compression.

My money is on the fact that ad blockers save several times the bandwidth per user that could possibly be saved by a switch away from JSON/XML.

Ignoring everything else there are much lower hanging fruit to save bandwidth.

Fwiw it seems like Fb moving away from Json had little to nothing to do with size of the data.

JSON and XML can also be wasteful on developer's time. I've seen a lot of time wasted in organizations where JSON was used as the communication medium between microservices (hundreds of them). Lots of time spent implementing parsers, watching out for changes, etc (of course, there's many process & culture "solutions" for these problems). Most of this goes away easily when you adopt a binary/IDL-based format (in the latest case I've been through, Thrift)

JSON/XML are the "dynamic language" of the transport protocols: flexible and quick to prototype, but can become very hard to "refactor" and performance suffers, as the thing grows.

As for public APIs, obviously agree with your point - it's a lot easier to roll out a JSON interface as parsing libraries are widespread, etc etc

I don't see how using JSON/XML or not has anything to do with the problem of communicating changes. The problem isn't the underlying serialization format, but what kind of schema validation, versioning and type definitions you build around it and how you make sure that all consumers know or may find out about it. Interestingly you mention Thrift, which can seamlessly use both XML and JSON as its underlying protocol.

Thrift and Protobuf both support JSON as transport, yes - it's useful when dealing with clients that can't support the binary encodings (eg browsers, last time I checked). It's an added benefit: you can use the fast encoding between clients that support it, but can fallback as needed.

The difference between communicating changes by setting a bunch of rules on how to do versioning/structure/etc vs changing an IDL is akin to verifying a program structure with unit tests and code reviews vs enforcing them with a compiler (sure, you can always use stuff like Json Schema or XSLT - personally never had a good experience w/ those). The latter is far easier, in my experience.

Fully agree, the human readability of json and xml is "fake productivity", it tricks you into thinking the format is easy and invites you to do hacks like manually writing the serialization and only helps you short term.

I've worked in places where binary serialization + deserialization functions were generated automatically by just adding a field and the bit-mapping into a message-spreadsheet. This was way more productive than misspelling the property name of a json-field between serializing and de-serializing and spending a whole day troubleshooting that. This also automatically documented the format instead of sending an example xml-file to your counterpart who is to implement loading of the data elsewhere and saying "the data will look aproximately like this". Viewing the data for debugging was done with a special program (similar to wireshark) that understood the protocol and rendered a much nicer view of the data than pasting a json-file into notepad++, there you need indentation and highlighting plugins anyway so the number of programs you need installed is not an argument either, streaming data through notepad++ doesn't work so well either if you want to view data on the fly.

Security is also one aspect, at every place i've worked there is always one smartass that thinks xml can be created by string-concating, that's impossible if the serialization-functions are totally encapsulated.

All this isn't a problem inherent to xml/json as it can all be solved with proper processes, it's just that it invites to that type of culture.

> After all, programmers are expensive. Hardware is cheap.

Except in China. I worked at a US company that did almost zero optimization on their code, deploying to 5000 AWS instances with a team of about six. In China, bandwidth closely followed by CPU were the cost centers, and the Chinese team of 30 engineers optimized the same code to run on around 50 (admittedly beefy) servers.

Doesn't invalidate the point; another EC2 instance is a few dozen bucks a month to run full time; another developer, even overseas, is going to cost you more, at just 40 hours a week.

But that said, it's rather a good thing to point out for the OP, as Joe Armstrong himself tends to value programmer time over a machine's, and that micro-optimizations are rarely ever worth it (as opposed to yours, which sounds like there were huge, glaring algorithmic issues to fix with macro optimizations, complete replacements of algorithms rather than tightening up code, careful profiling and tweaking to get a 30% speedup in one critical section, etc)

I guess your response brings out the fact that it's not an either-or proposition. It's a sliding scale between dev resources and computer resources, based on the costs in your situation.

Yes, the exact tradeoff has to be calculated per instance, exactly how much programmer time would it take to reduce how much machine time.

However, getting X hours of average programmer time, vs X hours of average machine time...machines are cheap. You should default to optimizing programmer time, not machine time.

4950 instances times a few dozen bucks a month, is like 2 million a year, just saying.

And then you notice that companies that have to be profitable care, while that are just burning through VC money don't.

This matters for VC funded companies too.

I just moved a customer off EC2. A small startup. I've billed them about $20k for the work. It will take them ~2.5 months to repay in saved hosting costs at current load levels. But if they're still at current levels in 3 months time, something is wrong. On top of that their ops costs have dropped as we have more control over the environment.

Basically, with rapidly growing hosting needs, getting a more cost effective setup was a matter of survival: They'd be unlikely to close another round of funding in the next few months if they didn't get that cost under control.

I wonder how many startups fail because they don't understand how to get their hosting costs under control, as it's way too common that I see developers that seem to think that servers are basically free, and managers that have no clue they need to seriously question why developers are making the server choices they are making..

Oh, it definitely should matter.

But, as we see with Twitter, it often is completely ignored.

Luckily WhatsApp gave some inspiration for companies to reverse this ideal.

You missed the point. I was just pointing out that 1 unit of hardware, compared to 1 unit of developer, is cheap. That was what the OP was commenting on.

Obviously, 4950 units of hardware, repeated monthly into perpetuity, compared with 30 units of developer, for a fixed length project, is not cheaper.

30 developers in a cheap country cost less than 2 million per year I think. I'm not 100% of their wages and taxes though

I think part of what he's getting at is that if things embrace simplicity in their design, suddenly fact that "every programming language has a json parser" becomes less compelling, because it's easy to write this stuff yourself.

Perhaps he goes a little bit far, but I'd agree that shoehorning your data serialization problems into a ubiquitous format can be a real headache.

> When sent over the wire, JSON and XML are typically compressed with gzip or deflate.

…which probably amounts to CPU-years of wasted time and electricity, considering how ubiquitous this is.

This could make for a really interesting data visualization.

There are probably lots of things we do as programmers that are insignificant in the context of our own systems, but are so culturally ubiquitous that they add up to an enormous impact globally. I wonder how even things like different application architecture would consume different amounts of power. Or,is there a side effect of shifting computation to the client side of causing more energy to be consumed from dirtier sources, if, say, data centers tend to draw from cheap and clean hydro power.

Even with binary protocols, compression is worthwhile. No matter your serialization format, most of the bytes transferred are going to be payload. And most of the time, that payload is going to have redundancies. Also, modern implementations of decompression algorithms are very efficient. Mobile SoCs can approach 100MB/sec for deflate. In other words: If your phone downloads 10GB of compressed data a month, it's going to use an extra 3-4 seconds of CPU time per day. That's a rounding error. In fact, it's quite possible that the radio power savings outweigh that extra CPU usage.

The problem with compression is, it's everywhere.

Sending a jpeg, over compressed http(s), throught a compressed and encrypted VPN is too much compression. Then the client may save the jpeg to a local compressed NTFS cache... This is just wasted performance, plus compressors are a common place for bugs, so this is also a security issue.

Just stop adding compression to everything and think about it first, and then Mobile phones and modem lines may very well be an exception.

The other question about compressed JSON/XML, is how may clock cycles are getting spent on this that wouldn't be otherwise. Which on mobile devices is going to translate to power consumption.

You probably would be surprised to realize that sane engineers nowadays are using this or that variant of "protocol buffers".

Also there is a theoretical knowledge that nothing could beat messages of fixed-length headers with adjustable-length payloads of binary tagged data.

Compression only works well if there is a lot of repetition of key names in the stream being compressed. If you are sending individual objects it may not be able to do much. And compression will never be able to eliminate brackets and commas.

You are right that for the majority of applications json is fine.

> And compression will never be able to eliminate brackets and commas.

Isn't that the whole point of compression: to minimise repetition of common features in data?

This'd be worth testing. Isn't the way gzip works to build up a dictionary of characters/phrases and then store pointers to the dictionary? I'm not sure you can compress { or } but }); is another story.

I just ran that experiment: https://gist.github.com/ggreer/4eb3ad61e97926e559f6

ASCII is extremely repetitive. 1MB of random braces gzips down to 163KB. That's a compression ratio of 6.1:1. Optimal compression would be close to 8:1 (since each byte really contains only one bit of information).

for (let i = 0; i < 1024 * 1024; i++) { buf += Math.random() > 0.5 ? "{" : "}"; }

Your sample data is bunk for determining the compression characteristics of braces in a realistic json file.

The point was to show that compression works at the level of bits, not characters. Realistic JSON is mostly content, which means your compression ratio depends more on content redundancies than braces or quotes. So too for binary serialization formats.

Gzip uses DEFLATE, which uses Huffman coding.

Huffman coding works by replacing common symbols with shorter codes and uncommon symbols with longer codes.

The codes used are therefore variable-length.

The codes are created in such a way that no code is the prefix of any other code.

That way, the decoder is able to know when it has reached the end of a code without the need for extra information other than the Huffman tree, which tells the decoder which codes belong to which symbols.

The Huffman tree can be pre-agreed or, more commonly, included with the compressed data.