4 ms·

For the same reasons we are in the process of switching from Protocol Buffers back to JSON: * It does not support our languages. Is there a Ruby module with no

For the same reasons we are in the process of switching from Protocol Buffers back to JSON: * It does not support our languages. Is there a Ruby module with no C extension? A C# library? Lua? What about that really cool language coming out next week? What about C? * Even if it does, why have to deal with someone else's poor API design? JSON has a million parsers for everything, and if by chance you don't like any of them, you can write another one in about two hours. * It's not human-readable. Enough said. * It's smaller than JSON, sure, but is it smaller than gzipped JSON? PB's aren't for our purposes. Neither are TNetstrings. This might be, I haven't checked, but I doubt it.

haberman 15y ago
> Is there a Ruby module with no C extension? Why is the "with no C extension" part important to you?
- arockwell 15y ago
  This is important if you want to use JRuby.
  - nupark2 15y ago
    There's a protobuf java library.
    - andrewvc 15y ago
      And a jruby messagepack library
  - randrews 15y ago
    Exactly! Also IronRuby. Or MRI on Windows for a lot of extensions, which just won't build there.
- andrewvc 15y ago
  By the way, there is a pure ruby version, not sure why you'd use it over the cext though: https://github.com/hiroshinakao/msgpack-pure https://github.com/hiroshinakao/msgpack-pure
  - halostatue 15y ago
    JRuby. Windows, if you don't have the compile stuff installed. This could be alleviated with Ruby FFI on top of a really good C implementation, but FFI is tricky.
nupark2 15y ago
> 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.
BasDirks 15y ago
It does not support our languages. Is there a Ruby module with no C extension? A C# library? Lua? What about that really cool language coming out next week? What about C? Exactly. I love having JSON libraries at my disposal no matter whether I'm coding in Python, C, Haskell, Racket, JS, whatever. That's hard to beat for coders like me (generalists).

haberman 15y ago

> Is there a Ruby module with no C extension? Why is the "with no C extension" part important to you?

arockwell 15y ago
This is important if you want to use JRuby.
- nupark2 15y ago
  There's a protobuf java library.
  - andrewvc 15y ago
    And a jruby messagepack library
- randrews 15y ago
  Exactly! Also IronRuby. Or MRI on Windows for a lot of extensions, which just won't build there.
andrewvc 15y ago
By the way, there is a pure ruby version, not sure why you'd use it over the cext though: https://github.com/hiroshinakao/msgpack-pure https://github.com/hiroshinakao/msgpack-pure
- halostatue 15y ago
  JRuby. Windows, if you don't have the compile stuff installed. This could be alleviated with Ruby FFI on top of a really good C implementation, but FFI is tricky.

nupark2 15y ago

> 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.

BasDirks 15y ago

It does not support our languages. Is there a Ruby module with no C extension? A C# library? Lua? What about that really cool language coming out next week? What about C? Exactly. I love having JSON libraries at my disposal no matter whether I'm coding in Python, C, Haskell, Racket, JS, whatever. That's hard to beat for coders like me (generalists).