> It does not support our languages. Is there a Ruby module with no C extension? This first part was already addressed in another comment, but ... > A C# libr

> It does not support our languages. Is there a Ruby module with no C extension? This first part was already addressed in another comment, but ... > A C# library? Lua? What about that really cool language coming out next week? What about C? ... yes. > It's not human-readable. Enough said. "Enough said" is glib, but it doesn't seem obvious to me. The computer is the one using the data the vast majority of the time, not a human. I'd rather optimize for that, improve the user experience and reduce parsing overhead, and use protobuf --decode for my own debugging. > It's smaller that JSON, sure, but is it smaller than gzipped JSON? Is GZIP'd JSON smaller than GZIP'd protobuf? What is the decoding time of a GZIP'd JSON file vs a non-GZIPd protobuf file? Regardless, all of these reasons seem to be more about making your life mildly easier (or at least more closely matching your preferences), and less about optimizing for CPU and bandwidth utilization of the client interface. We just switched to protobuf because it allowed us to provide the best user experience by decreasing both parse time and transmission cost, AND we can auto-generate the serialization code, including validating the messages for correctness. If anything, I'd choose to move to an even more rigorous message specification format, as having the validation done for us automatically keeps our client-side code very simple compared to the data extraction and type validation we have to write manually with JSON.