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.
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.
"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.
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.
I would always go to the official docs page for the needs I have, and use their HTTP library (or any other). It removes decision making, having to ensure good quality practices from lesser known libraries, and risks of supply chain attacks (assuming the root stdlib of a language would have more attention to detail and security than any random 3rd-party library thrown into github by a small group of unpaid devs)
Only when it falls short on my needs, I would drop the stdlib and go in dearch of a good quality, reputable, and reliable 3rd-party lib (which is easier said than done).
Has worked me well with Go and Python. I would enjoy the same with Rust. Or at a minimum, a list of libraries officialy curated and directly pointed at by the lang docs.
True zero-copy is not achievable with Protobuf, you need something like FlatBuffers for that. What is presented here is more like a zero-allocations.
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.
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.
"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.
Commonly used crates should be blessed and go into an extended stdlib.
Ok, but this is not a commonly used crate. Its brand new!
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
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.
I would always go to the official docs page for the needs I have, and use their HTTP library (or any other). It removes decision making, having to ensure good quality practices from lesser known libraries, and risks of supply chain attacks (assuming the root stdlib of a language would have more attention to detail and security than any random 3rd-party library thrown into github by a small group of unpaid devs)
Only when it falls short on my needs, I would drop the stdlib and go in dearch of a good quality, reputable, and reliable 3rd-party lib (which is easier said than done).
Has worked me well with Go and Python. I would enjoy the same with Rust. Or at a minimum, a list of libraries officialy curated and directly pointed at by the lang docs.
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