Is there really any good reason for code-gen? Just because “google did it” doesn’t mean it’s a good idea.
How about because for deterministic output, it suits the problem? Just because you can do it by hand doesn't mean I want to.
Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
11–20 of 54 posts
Re: Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
#12[deleted]
Re: Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
#13There's already 6 different protobuf libraries for Rust: [1] I've chosen Prost for our project, but see the whole list: https://github.com/stepancheg/rust-protobuf#related-projects
It's 'only' really 4 (two of them are gRPC implementations).
But yeah - this is one of those things that makes me stay with Go instead of moving over to Rust for my backend SOA/microservice work. In Rust, for everything you need to do, there's at least 5 different libraries that implement that, all competing with eachother. This is especially annoying when dealing with transitive dependencies. Meanwhile in Go, you generally get one choice - it might be not great, but that's fine, it doesn't have to be.
EDIT: This is not intended to be mindless bashing of Rust. I do use Rust for other things. It's a fine language.
Re: Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
#14There's already 6 different protobuf libraries for Rust: [1] I've chosen Prost for our project, but see the whole list: https://github.com/stepancheg/rust-protobuf#related-projects
It's 'only' really 4 (two of them are gRPC implementations). But yeah - this is one of those things that makes me stay with Go instead of moving over to Rust for my backend SOA/microservice work. In Rust, for everything you need to do, there's at least 5 different libraries that implement that, all competing with eachother. This is especially annoying when dealing with transitive dependencies. Meanwhile in Go, you ge…
There are at least two Go protoc plugins, protobuf-go and gogoproto.
Re: Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
#15I know it's common and perhaps even fashionable, but FWIW language like "We take an opinionated stance" utterly puts me off caring about this package
It's a piece of software, it has a design that is either fit for purpose or not. When ego becomes entangled in that design process, it's a strong indicator of the kind of experience one might have trying to get fixes or enhancements merged, or even the kind of attitude you'd find when attempting to report a bug.
Re: Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
#16Cool. It would be interesting to compare benchmarks the RPC latency under heavy load for pb-jelly compared to other RPC methods.
Rust has such great support for performant zero copy serialization and de-serialization in various formats (bincode, message pack, cbor, bson). Seeing this for protobuf feels very encouraging.
Re: Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
#17I know it's common and perhaps even fashionable, but FWIW language like "We take an opinionated stance" utterly puts me off caring about this package It's a piece of software, it has a design that is either fit for purpose or not. When ego becomes entangled in that design process, it's a strong indicator of the kind of experience one might have trying to get fixes or enhancements merged, or even the kind of attitude…
That's not what the word 'opinionated' means here. It's not any one person's opinion; it's that the project overall takes a stance on an issue rather than leaving everything open for everyone else to figure out. It provides clarity and direction compared to the more difficult situation where every library is completely general. No ego involved at all.
Re: Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
#18Is there really any good reason for code-gen? Just because “google did it” doesn’t mean it’s a good idea.
Type safety for your serialization/RPC layer.
Protobuf does not provide any type safety whatsoever. The name of the type of the message is carried in a side-channel, and the interpretation of that name is completely up to the endpoint that deserializes the message.
Re: Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
#19Is there really any good reason for code-gen? Just because “google did it” doesn’t mean it’s a good idea.
code generation is great for sharing data models and writing clients for services without dependencies
Re: Pb-jelly – A Protobuf code generation framework for Rust, developed at Dropbox
#20I know it's common and perhaps even fashionable, but FWIW language like "We take an opinionated stance" utterly puts me off caring about this package It's a piece of software, it has a design that is either fit for purpose or not. When ego becomes entangled in that design process, it's a strong indicator of the kind of experience one might have trying to get fixes or enhancements merged, or even the kind of attitude…
That's not what the word 'opinionated' means here. It's not any one person's opinion; it's that the project overall takes a stance on an issue rather than leaving everything open for everyone else to figure out. It provides clarity and direction compared to the more difficult situation where every library is completely general. No ego involved at all.
Perhaps I misunderstand the text in the README. Who is "we" in this case? Is the software writing its own README?