Request for Thrift RPC support

[johnynek]

Experimenting with Rust will be a lot easier in our org if we can build standalone services implementing thrift APIs. Since we already use thrift, it will be an easy sell to try rust since we can stop at any point an reimplement the service in Java/scala if need be.

[brson]

I didn't know what thrift was: https://thrift.apache.org/

There's a lot that has to happen to make this possible, but it would be a fun and useful project.

[kud1ing]

I agree, having Rust support for ProtocolBuffers, Thrift, Etch and JSON-RPC would be very nice.
Do we see this being part of libstd?

[brson]

IMO these are too domain-specific for std.

[graydon]

I'm ok with libstd carrying these. Not libcore, but "general purpose serialization formats" tend to be pretty small. Even ASN.1 is ok. These are typically really well defined, stable, have no external dependencies, are easy to implement and test, useful in a slew of contexts, and take little space to implement.

The EBML code in libstd is 229 lines of code and consumes 4035 bytes of compiled code in the resulting library.

We've also discussed these libraries arriving in libstd before:

https://github.com/mozilla/rust/wiki/Note-wanted-libraries

and, fwiw, "large standard libraries" seem to be the norm in recent languages. See python, ruby, go standard libraries:

http://docs.python.org/library/
http://ruby-doc.org/stdlib-1.9.3/
http://golang.org/pkg/

About the only things new languages are shying away from in the standard libraries are desktop-GUI libraries like QT and GTK (at least, any beyond tk). Because those usually outmass the remainder of the library, are very project-specific, and typically bring their own standard libraries along for the ride.

[nikomatsakis]

@graydon @brson isn't our new plan to move libstd out into rustpkg? do we still expect to ship these sorts of bindings as part of the stdlib?

[catamorphism]

Bug triage. Still on the wishlist.

[alexcrichton]

Closing due to inactivity. Functionality like this doesn't belong in libstd, and libextra is going to be dissolved in the future, so this would be best suited implemented as a separate library. There's been very little activity on this, and I don't think that this is an issue for the compiler as a whole, but rather just a general wishlist of libraries that exist.