3 ms·
This seems pretty confused. The "compiled vs dynamic" distinction is a property of the implementation, not of the protocol. For example, you can certainly comp
by spenczar5 5y ago
This seems pretty confused. The "compiled vs dynamic" distinction is a property of the implementation, not of the protocol.
For example, you can certainly compile Avro into Go source files [0]. You can even compile Avro loaded schemas _during runtime_ into Python bytecode, since Python is interpreted [1]. This even works if you have the _wrong schema document_ for the message (you'll just get the subset of fields which are accurately described), because of Avro's schema compatibility rules.
Likewise, you can deserialize arbitrary protobuf messages during runtime without a compilation step, if you have a description for the message schema. The Python protobuf library has had a "ParseMessage" API forever, and protoreflect [2] exists for Go. (In case it's not obvious, I mostly work in Python and Go but I am completely certain analogues exist in other major languages).
There is a very big and important difference between a protocol and the implementation of a protocol. I think this README's author is not clear on that difference, which shows up in other claims ("Deserialization is incrimental", for example) too.
---
[0] https://github.com/actgardner/gogen-avro https://github.com/actgardner/gogen-avro
[1] https://github.com/spenczar/avroc https://github.com/spenczar/avroc
[2] https://pkg.go.dev/google.golang.org/protobuf/reflect/protoreflect https://pkg.go.dev/google.golang.org/protobuf/reflect/protor...
- mumblemumble 5y agoTo add to that, protobuf even some facilities for self-describing messages. gRPC has a reflection API so that you can dynamically download the schema for messages. It's a lot like Swagger only it works better with less effort.