
MessagePack: Efficient, Cross Language Binary Object Serialization - jasonwatkinspdx
http://www.rubyinside.com/messagepack-binary-object-serialization-3150.html
======
avstraliitski
This is lame and not HN-worthy because the use cases are almost zero.

0\. Premature optimisation is the root of all evil 1\. Approximately zero big
sites use ruby 2\. Of large sites, very few would actually care that much
about tiny on-wire messaging optimisation since other elements are far more
significant to bandwidth use. 3\. On-wire messaging in binary destroys
transparency, which means PITA debugging and wasted programmer and API-using
developer time. Programmer time is far more important than computer time or a
few bytes of bandwidth in most developed nations. 4\. You have to pay for the
binary serialisation with additional client-side code, which means you've
actually gone backwards until you've communicated enough that the delta
between JSON and binary format message sizes have outgrown this initial load
time penalty. 5\. Initial load time penalties are often more important than
subsequent use, since generally this is the only time client bandwidth (the
only side of the bandwidth equation relevant to performance in 99.99% of
cases) is going to be challenged to any serious level. 6\. Refer to point
zero.

~~~
jasonwatkinspdx
Good lord you're a troll.

0\. Few people who use this quote actually know its origin and context.

1\. Scribd, Hulu, Justin.tv, Slideshare... there are tons of ruby sites in the
top 500, not just Twitter.

2\. Serialization isn't just on the wire, it also may be stored in memcache or
the like. But even on the wire, crossection bandwidth is scarce in large
clusters. There's a reason google developed protocol buffers.

3\. Debugging by wire sniffing is shitty period. I don't think binary vs ascii
is very meaningful. What matters more is the infrastructure on each end, eg do
the client and server have good reflection, monitoring and logging
capabilities. These are what affect programmer time.

4\. This is a RPC format. Sending payloads to browsers is not a use case. Even
so on modern javascript implementations decoding a byte packed binary format
is likely faster than the eval path used by naive browser JSON parsers because
it doesn't build any intermediate forms like token streams, ASTs, etc.

5\. Same as 4.

Your view is both myopic and hyperbolic.

