That whole topic has been discussed on SO already.

TL;DR:

- Thrift has 20+ languages out of the box, and RPC out of the box. It is 
flexible and highly agnostic when it comes to transports or protocols.

- protobuf supports that as well, but is more cumbersome to set up, because 
everything (including grpc and basically every target language) is a plugin, 
an addon, or 3rdparty project which wants a special syntax to get it to work

- gRPC biggest plus: it has built-in support for streaming, which requires 
much more work with Thrift
- gRPC biggest minus: you want to use HTTP/2, because that's the only option 
you have

- Both work and are used by lots of companies and projects.

Bottom line: You don't have to eat meat. You can live vegan and be proud of 
it, as long as you compensate what your project actually needs. Both is 
perfectly fine.



-----Ursprüngliche Nachricht----- 
From: Edward Capriolo
Sent: Tuesday, February 20, 2018 9:58 PM
To: user@thrift.apache.org
Subject: Re: Thrift vs. Protocol Buffers

"Last I looked at protobuf it was just a framework for serialization, and
the rest was left to the reader."

Many are using this now: Protobuf is often pared with https://grpc.io/

On Tue, Feb 20, 2018 at 3:41 PM, James E. King, III <jk...@apache.org>
wrote:

> That's an interesting angle; I haven't looked into it though.
> It might be possible to use a protobuf protocol layer but you would have 
> to
> provide that yourself.
>
> One of the strengths of thrift is that it generates the client and server
> code for you, and provides libraries for over 20 languages
> that are decently tested against each-other for interoperability.
> Last I looked at protobuf it was just a framework for serialization, and
> the rest was left to the reader.
> Multi-threaded servers are fairly complex machines...
>
> It's all just bytes on a wire; so it should be possible to achieve some
> level of interoperability; you will probably run into issues
> with things like optional/required/default parameters (if one supports it
> and one does not), and thrift service methods
> won't translate into protobuf structures.
>
> - Jim
>
>
> On Fri, Feb 16, 2018 at 1:04 PM, James Hanley <jhan...@dgtlrift.com>
> wrote:
>
> > A number of years back, Diwaker Gupta published a great article
> > "Thrift vs. Protocol Buffers" which eventually moved to
> > https://old.floatingsun.net/articles/thrift-vs-protocol-
> buffers/index.html
> > and then later another article titled "Thrift: The Missing Guide"
> > landing on https://diwakergupta.github.io/thrift-missing-guide/ also
> > highlighting some of the differences between the two and the
> > reasoning.
> >
> > Is there any additional updated documentation as these are around 3 to
> > 5 years old comparing some of the capabilities of each?
> >
> > Also, it wasn't completely obvious but if I want to implement an
> > application that interoperates with a system implemented with Protocol
> > Buffers, the application must also use PB and cannot use Apache Thrift
> > with a Thrift Protocol that will interoperate with Protocol Buffer
> > encoding/decoding? My guess is either that is not possible due to
> > design decisions regarding signed values in Thrift and/or enum
> > definitions - or possible but not implemented.
> >
> > Part of the attraction to AT is that the protocol can be abstracted
> > regardless of implementation or language choice, but we need to also
> > interoperate with systems implemented using Protocol Buffers.
> >
> > Thanks in advance for insight,
> > -Jim
> >
> 

Reply via email to