Zero-copy protobuf and ConnectRPC for Rust
21 points by PaulHoule 4 days ago | 8 comments

arianvanp 16 minutes ago
I've been running into _a lot_ of issues with Hyper/Tonic. Like literal H2 spec violations. Try hosting a tonic server behind nginx or ALB. It will literally just not work as it can't handle GOAWAY retries in a H2 spec-compliant way.

If this fixes that I might consider switching.

However, Google is also working in a new grpc-rust implementation and I have faith in them getting it right so holding tight a little bit longer.

reply
secondcoming 54 minutes ago
Google really dropped the ball with protobuf when they took so long to make them zero-copy. There are 3rd party implementations popping up now and a real risk of future wire-level incompatibilities across languages.
reply
jeffbee 50 minutes ago
"zero copy" in this context just means that the contents of the input buffer are aliased to string fields in the decoded representation. This is a language-level feature and has nothing to do with the wire format.
reply
slipknotfan 4 days ago
Commonly used crates should be blessed and go into an extended stdlib.
reply
josephg 2 hours ago
Ok, but this is not a commonly used crate. Its brand new!
reply
alfiedotwtf 30 minutes ago
Unless there’s a strict schedule for review to remove them, please no… because that’s how we get BerkeleyDB and CGI in the standard Perl libraries.

If anything, there should be “less than blessed” “*-awesome” libraries

reply
echelon 51 minutes ago
No HTTP, Proto, or gRPC crate should ever find itself in the stdlib.

Didn't we learn this with python?

How many python http client libraries are in the dumping ground that is the python "batteries included" standard library?

And yet people always reach for the one that is outside stdlib.

reply
Valodim 25 minutes ago
You don't think golang's http library is a good idea? I would have thought everyone is happy we have it
reply