Zero-copy protobuf and ConnectRPC for Rust
1–10 of 47 posts
Re: Zero-copy protobuf and ConnectRPC for Rust
#2Commonly used crates should be blessed and go into an extended stdlib.
Re: Zero-copy protobuf and ConnectRPC for Rust
#3Commonly used crates should be blessed and go into an extended stdlib.
Ok, but this is not a commonly used crate. Its brand new!
Re: Zero-copy protobuf and ConnectRPC for Rust
#4Google 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.
Re: Zero-copy protobuf and ConnectRPC for Rust
#5Commonly used crates should be blessed and go into an extended stdlib.
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.
Re: Zero-copy protobuf and ConnectRPC for Rust
#6Google 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.
"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.
Re: Zero-copy protobuf and ConnectRPC for Rust
#7Commonly used crates should be blessed and go into an extended stdlib.
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
Re: Zero-copy protobuf and ConnectRPC for Rust
#8Commonly used crates should be blessed and go into an extended stdlib.
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.
You don't think golang's http library is a good idea? I would have thought everyone is happy we have it
Re: Zero-copy protobuf and ConnectRPC for Rust
#9I'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.
Re: Zero-copy protobuf and ConnectRPC for Rust
#10Commonly used crates should be blessed and go into an extended stdlib.
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.
On the other hands, having half the packages depend on packages such as serde, syn, procmacro2 might not be such a good idea. First of all it is annoying when creating new projects to have to move over table stakes. Second, it is a security nightmare. most of rust could be vulnerable if dtolnay decided to go rogue.
It is not that everything should go into the stdlib, but having syn, procmacro and serde would be a good start imo. And like golang having a native http stack would be really awesome, every time you have to do any HTTP, you end up pulling in some c-based crypto lib, which can really mess up your day when you want to cross-compile. With golang it mostly just works.
It isn't really in the flavor of rust to do, so I don't think it is going to happen, but it is nice when building services, that you can avoid most dependencies.