Add examples in all supported languages

[PhilipMetzger]

As far as I can see fbthrift supports all major languages which are used at Meta (Hack, Cpp, Rust, Python and Java ¹) but the examples directory only contains a simple Python and Cpp client/server example.

Hopefully this is just a port of internal examples.

Thanks.

Footnotes

1. Taken from https://engineering.fb.com/2022/07/27/developer-tools/programming-languages-endorsed-for-server-side-use-at-meta/ ↩

[robberphex]

Well, this repo is faulty and not useful.

1. fbthrift is not buildable

Unfortunately, this code is only buildable with Facebook internal build system "Buck".
Buck itself is open-sourced (https://buck.build/) but the build files are full of internal references which would make it impossible to use outside of Facebook.

Originally posted by @stevegury in #364 (comment)

2. fbthrift even cannot run normally

At client, "MethodName" will be convert to "method_name", like this:

fbthrift/thrift/compiler/test/fixtures/basic/out/java/gen-java/test/fixtures/basic/FB303ServiceReactiveClient.java

Lines 98 to 99 in 70d9d75

	org.apache.thrift.RequestRpcMetadata _metadata = new org.apache.thrift.RequestRpcMetadata.Builder()
	.setName("simple_rpc")

But for server, "MethodName" is still "MethodName", like:

fbthrift/thrift/compiler/test/fixtures/basic/out/java/gen-java/test/fixtures/basic/FooServiceRpcServerHandler.java

Lines 190 to 192 in 70d9d75

	switch (_name) {
	case "simpleRpc":
	_result = _dosimpleRpc(_delegate, _payload, _simpleRpcReaders, _chain);

Caused TApplicationException: no method found with name simple_rpc.

I didn't know why there is an convertion, what is .thrift file has two method simple_rpc and simpleRpc?

3. fbthrift lacks document, you couldn't find any document for use fbthrift.

There is only source code, which is not buildable.

4. fbthrift pollute search engine

When talking thrift, developers have to distinguish which thrift, apache thrift or fbthrift.

[robberphex]

Thrift holds a significant position in the history of RPC (Remote Procedure Call) frameworks as it is truly a remarkable one and was among the earliest developed in this domain. It once boasted a series of features that made it a popular choice among developers in the early days of RPC development. For instance, it provided efficient ways to enable communication between different services across various programming languages, facilitating the building of distributed systems. However, as the technology landscape has evolved rapidly over time, it's rather disheartening to witness that Thrift's influence in the RPC field has waned to such a considerable extent nowadays.

One of the major issues plaguing Thrift is the fragmentation within its community. Specifically, it has diverged into two main branches, namely apache thrift and fbthrift. This split has led to a lack of cohesive development efforts. Different teams or individuals might be working on these separate branches, resulting in inconsistent feature implementations, compatibility challenges between the two variants, and a general confusion for users who are trying to decide which one to adopt.
Another problem that can't be overlooked is its relatively low developer-friendliness. When developers evaluate a framework for their projects, aspects such as straightforward APIs, comprehensive and clear documentation, easy onboarding processes, and convenient debugging tools are of utmost importance. Unfortunately, Thrift falls short in some of these areas. Its APIs might not be as intuitive as those of some modern RPC frameworks, making it take longer for developers to understand and utilize them effectively. The documentation might also lack clarity or be incomplete in certain aspects, causing developers to struggle when they encounter issues during the development process. All these factors combined make it less appealing compared to other options available in the market.

Subsequently, with the emergence of gRPC, which has come to the fore with its own set of powerful features and advantages, Thrift has been gradually overshadowed. gRPC, built on top of the HTTP/2 protocol, offers high performance, seamless cross-language support, and excellent compatibility with the cloud-native ecosystem. It has managed to attract a large number of developers and enterprises, gradually taking over the spotlight in the RPC domain that Thrift once held. This shift in the landscape is truly a pity considering Thrift's historical contributions and potential.