New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for Thrift RPC support #1677

Closed
johnynek opened this Issue Jan 26, 2012 · 7 comments

Comments

Projects
None yet
7 participants
@johnynek

johnynek commented Jan 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 26, 2012

Contributor

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.

Contributor

brson commented Jan 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@kud1ing

kud1ing Jan 27, 2012

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

kud1ing commented Jan 27, 2012

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jan 28, 2012

Contributor

IMO these are too domain-specific for std.

Contributor

brson commented Jan 28, 2012

IMO these are too domain-specific for std.

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Feb 16, 2012

Contributor

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.

Contributor

graydon commented Feb 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis May 13, 2013

Contributor

@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?

Contributor

nikomatsakis commented May 13, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism Jul 29, 2013

Contributor

Bug triage. Still on the wishlist.

Contributor

catamorphism commented Jul 29, 2013

Bug triage. Still on the wishlist.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Dec 18, 2013

Member

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.

Member

alexcrichton commented Dec 18, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment