43

I've been using PB for quite a while now, but, Thrift has constantly been at the back of my mind.

The primary advantages of thrift, as I see it are:

  1. Native collections (i.e, vector, set etc) vs PBs repeated providing functionality similar to, but not quite like (no iterators unless you dig into RepeatedField which the documentation states "shouldn't be required in most cases").
  2. A decent RPC implementation provided, instead of just hooks to plug your own in.
  3. More officially supported languages (PB offers "official" support for Java, C++, Python)

The cons of Thrift:

  1. The RPC implementation means I can't plug in my own (for example) encryption/authentication layer on top.
  2. Windows support doesn't seem to be great.
  3. PB definitely seems to have, if not better, more accessible documentation.

Neutral:

  • Unknown size of .lib/.dll on Windows (Thrift).
  • Large size of .lib on Windows (PB, but it does offer a -lite which is significantly smaller).
  • Speed wise, they both seem to be similar.

I'm not quite ready to take the plunge and switch to Thrift yet, can anyone offer me more pros/cons, or reasons to go one way or the other?

Thanks!

jamessan
  • 41,569
  • 8
  • 85
  • 85
please delete me
  • 711
  • 2
  • 9
  • 17
  • It's considered good style to put updates in a separate section instead of overwriting the original question. :) – awdz9nld Nov 07 '12 at 14:18
  • You can actually add your own encryption/authentication layer. You just need to write an alternative TTransport class. Or something like that.. there is a TSSLSocket class in there somewhere. – Timmmm Jan 08 '13 at 11:57
  • Old question, I know. Just want to mention that Thrift's Windows support has been improved heavily since 2010. – JensG Jan 18 '14 at 12:09

4 Answers4

18

As I've said as "Biggest differences of Thrift vs Protocol Buffers?" topic :

Referring to Thrift vs Protobuf vs JSON comparison :

Additionally, there are plenty of interesting additional tools available for those solutions, which might decide. Here are examples for Protobuf: Protobuf-wireshark , protobufeditor.

Harald Gliebe
  • 7,236
  • 3
  • 33
  • 38
Grzegorz Wierzowiecki
  • 10,545
  • 9
  • 50
  • 88
  • **This information is outdated.** [Here's the most recent version](http://stackoverflow.com/a/7216455/499466) – JensG Jan 27 '15 at 09:21
9

You might want to analyse your need first:

Do you need a protocol-agnostic format? For example, do you want to implement a custom protocol or need 100% portability? In such a case use PB.

If you are fine with the default protocol of Thrift, and you need a protocol to begin with, by all means, go with Thrift.

Hope this helps.

awdz9nld
  • 1,663
  • 15
  • 26
8

Our project's main reason to stick with Thrift over protocol buffers was that protocol buffers don't auto-generate a complete RPC server, and existing solutions for PB seemed to all be fairly unstable. Just my $0.02.

alexras
  • 397
  • 1
  • 8
0

You need to specify your use case(s) in detail. Else this is a "Which is better, a car or a truck?" question.

John Zwinck
  • 239,568
  • 38
  • 324
  • 436
  • 11
    Not really; the use cases for both Thrift and Protocol Buffers are similar. They're both, at the basic level, generic ways to implement cross-platform data serialization. On a higher level, both can be used to implement cross-platform client/server applications. They're both sufficiently generic that they can be used just as a serialization format, or as a building block in a bigger system. But, at their base, they provide the same thing. The question is, does is either implementation "better", at that? And, at a higher level, are the addon services provided worth it? (with Thrift). – please delete me Nov 29 '10 at 00:01
  • 1
    Let me put phrase it another way, then: can you rate the pros and then the cons that you listed from most relevant to your application to least relevant? Or on a scale of 1 to 10, for each, how much impact you see each having on your problem domain? I was seriously considering Protocol Buffers for a work project, but then I decided that the deal-breaker for me was lack of intrinsic message framing (you can't just write PBs to disk consecutively, you need an envelope for them). For some situations (UDP messaging, some forms of IPC, RPC), this wouldn't matter; for me it was a deal breaker. – John Zwinck Nov 29 '10 at 01:07
  • 1
    Oh, let me throw out another idea and see if it resonates with you: I think that the backers of Thrift have weaker long-term incentives to improve their product than do the backers of Protocol Buffers. – John Zwinck Nov 29 '10 at 01:11
  • 1
    @JohnZwinck - Can you explain why fb has less incentive to improve thrift than google does to improve pb? – pepsi Mar 28 '12 at 17:53
  • Holy ancient comment! I don't recall what I had in mind way back then, and anyway the comments shouldn't be a discussion forum. Anyway what I said was to "see if it resonates with you," so if it doesn't, just ignore what I said there. :) – John Zwinck Mar 28 '12 at 21:27